home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Developer Toolbox 6.1
/
SGI Developer Toolbox 6.1 - Disc 1.iso
/
toolbox
/
FAQs
/
SGIfaqs
/
SGI-Hardware-faq
< prev
next >
Wrap
Text File
|
1996-11-11
|
191KB
|
4,871 lines
SGI Hardware Questions and Answers
==================================
The following is a list of questions and answers culled from the last 1800
messages to comp.sys.sgi.hardware. Note that the first entry here is the
April 6, 1994 SGI Hardware FAQ list. It is also included in the
toolbox/hardware directory.
Where there were multiple answers, they are shown as
--- 1 ---
[............]
--- 2 ---
[............]
etc cetera.
---------------------------------------------------------------------------
Table of Contents
(1) - SGI Hardware FAQ
(2) - Moire Patterns
(3) - Disk problems on crashed system
(4) - Forced Perfect Terminators
(5) - Determining graphics mode
(6) - Printer port gets stuck
(7) - Maximum Memory capacity
(8) - Disk Striping Questions
(9) - Seagate ST42100N configuration
(10) - SCSI Timeout problems
(11) - Making a new Boot disk
(12) - Accessing VAX Tape Drives from Indigo
(13) - Indigo CPU/SCSI Board Problems
(14) - Exabyte 8205 on an Indigo2
(15) - Disks for Indy's
(16) - Indy Graphics
(17) - VME Interrupts
(18) - Extending Keyboard, Mouse and Video signals
(19) - More SCSI for Challenge M
(20) - Device Driver Guide for 4.x versus 5.x
(21) - Trouble with Indigo Disk Drive
(22) - Bru for floptical?
(23) - Using serial port to detect a switch closure
(24) - Toshiba XM3401BC on Indigo
(25) - Software protection
(26) - Using 'setmon'
(27) - Fastest Baud rate for serial ports
(28) - Odd baud rates
(29) - SCSI Devices on Twin Tower machines
(30) - Connecting Video Projectors to SGI platforms
(31) - Using 'sysid' for software licensing
(32) - Books about MIPS processors
(33) - Wangtek DAT on an Indy?
(34) - DAT drive on Power Series Systems
(35) - Serial Port & Modem Cabling for Indigo
(36) - FDDI/CDDI on Indigo2
(37) - Apple (or other) CD-ROM on SGI
(38) - Connecting Tektronix color printer to SCSI port
(39) - Disks for Challenge L
(40) - Multichannel Option Problems
(41) - Flicker on Indigo2
(42) - Fuji M2263SA on an Indy?
(43) - 4D/25 Boot problem
(44) - Maximum Memory on a 4D/25
(45) - Bru and M/O drives
(46) - VME Transfer Problems
(47) - Pio_bcopyin and pio_bcopyout arguments
(48) - DMA Rates on EISA & GIO
(49) - SGI Periodic Table
(50) - Quick Ring for Indy?
(51) - Reading audio from CD-ROM drive into aiff file
(52) - Determining current video scan rate
(53) - Using Vigra MMI-210 in a 4D/320S
(54) - Software upgrade required for R4400?
(55) - FDDI in Indigo2
(56) - 1024x768 support with Elan for projector
(57) - Reading data from DAT with a program
(58) - Replacement Indigo Keyboard?
(59) - Can't find tape drive on 4D/35
(60) - Will 525 MB tapes work in QIC 150 drives?
(61) - Second SCSI bus for Indigo?
(62) - Audio programming on Indigo2 (applies to Indigo and Indy as well)
(63) - Audio programming - part 2
(64) - Power Connections for SGI systems
(65) - Maxtor 8760E drive on 4D/240S
(66) - Panic crashes
(67) - Swap space or RAM?
(68) - Help with Exabyte 8505 tape drive
(69) - Indy Third Party Drive Problems
(70) - R2000A/R3000 - What does this mean?
(71) - Heat problems with Seagate Barracuda in an R4000 Indigo?
(72) - Optical Disk Drive suggestions?
(73) - Moving a drive from one machine to another
(74) - IO4 Bus arbitration question
(75) - Disk drive problem with Indigo
(76) - Print problems with LaserWriter Pro
(77) - NFS performance problems on 4D/35
(78) - Indigo Environmental Operating conditions
(79) - Apple CD-ROM - Part 2 [see (37)]
(80) - Difference between R4000 in Indigo and R4000PC in Indy
*******************************************************************************
(1) - SGI Hardware FAQ [1002 lines long]
---------------------------------------------------------------------------
From: sgi-faq@viz.tamu.edu (The SGI FAQ group)
Newsgroups: comp.sys.sgi.misc,comp.answers,news.answers
Subject: SGI hardware Frequently Asked Questions (FAQ)
Supersedes: <hardware_786697207@viz.tamu.edu>
Followup-To: comp.sys.sgi.misc
Date: 20 Dec 1994 06:57:15 GMT
Organization: Visualization Lab, Texas A&M University
Lines: 1159
Approved: news-answers-request@mit.edu
Expires: 17 Jan 1995 07:00:07 GMT
Message-ID: <hardware_787906807@viz.tamu.edu>
Reply-To: sgi-faq@viz.tamu.edu (The SGI FAQ group)
NNTP-Posting-Host: viz.tamu.edu
Originator: sgi-faq@viz
Archive-name: sgi/faq/hardware
Last-modified: Sat Dec 17 12:14:15 CST 1994
SGI hardware Frequently Asked Questions (FAQ)
This is one of the Silicon Graphics FAQ series, which consists of:
SGI admin FAQ - IRIX system administration
SGI apps FAQ - Applications and miscellaneous programming
SGI audio FAQ - Audio applications and programming
SGI graphics FAQ - Graphics and user environment customization
SGI hardware FAQ - Hardware
SGI impressario FAQ - IRIS Impressario
SGI inventor FAQ - IRIS Inventor
SGI misc FAQ - Introduction & miscellaneous information
SGI movie FAQ - Movies
SGI performer FAQ - IRIS Performer
SGI pointer FAQ - Pointer to the other FAQs
Read the misc FAQ for information about the FAQs themselves. Each FAQ
is posted to comp.sys.sgi.misc and to the news.answers and comp.answers
newsgroups (whose purpose is to store FAQs) twice per month. If you
can't find one of the FAQs with your news program, you can get it by
anonymous FTP from one of these sites:
viz.tamu.edu:/pub/sgi/faq/
rtfm.mit.edu:/pub/usenet/news.answers/sgi/faq/
ftp.uu.net:/usenet/news.answers/sgi/faq/
Note that rtfm.mit.edu is home to many other FAQs and informational
documents, and is a good place to look if you can't find an answer here.
If you can't use FTP, send mail to mail-server@rtfm.mit.edu with the
word 'help' on a line by itself in the text, and it will send you a
document describing how to get files from rtfm.mit.edu by mail. Send the
command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
and similarly for the other FAQs. Finally, the FAQs are on the World
Wide Web at
http://www.cis.ohio-state.edu/hypertext/faq/usenet/sgi/top.html
The SGI FAQs are freely distributable and we encourage wide circulation.
You MUST keep the FAQs intact, including headers and this notice. The
contents are accurate as far as we know, but the usual disclaimers
apply. (In particular, copies of the SGI FAQs published on paper or
CD-ROM are certain to be out of date!) Please send additions and changes
to sgi-faq@viz.tamu.edu.
Topics covered in this FAQ:
---------------------------
-1- GENERAL INFORMATION
-2- Where can I get a copy of SGI's Periodic Table of the Irises?
-3- What third-party vendors sell thus-and-such for SGIs?
-4- Where can I get used SGI machines?
-5- What is my old SGI machine worth?
-6- What about my IRIS 2000 or 3000?
-7- Should I shut off my Iris at night?
-8- How fast is my R4000 or R4400 machine?
-9- What is the IP number of each SGI model?
-10- MEMORY
-11- Can I mix 1MB and 2MB SIMMS in my 4D/20 & 4D/25 Personal IRISes?
-12- Can I add 4MB SIMMS to my 4D/20 or 4D/25 PI?
-13- How many 4MB SIMMS can be put into an Indigo?
-14- How can I find a bad SIMM?
-15- Why does my system tell me I need a revision C Memory Controller
(MC) chip?
-16- MONITORS AND VIDEO HARDWARE
-17- My monitor is maladjusted in some way. How to fix it?
-18- Can I have 2 graphics displays on my Indigo?
-19- What do I need to do stereo on an Onyx/RE2?
-20- Can I use my SGI monitor on my PC?
-21- Can I use my PC monitor on my SGI?
-22- What video formats, scan rate, etc. do SGI monitors support?
-23- How can I set my Indy to use 1280x1024 pixels on a third-party
monitor?
-24- STORAGE DEVICES
-25- What do all these SCSI technical terms mean?
-26- How many SCSI devices can I have on an Indigo?
-27- How do I install external SCSI disks on my SGI?
-28- What kind of DAT drive does SGI sell for the Indigo?
-29- Can I use a 3rd-party cartridge tape drive on my Indigo?
-30- Which Exabyte drives work with SGI systems?
-31- How to connect my 3rd-party tape drive to my SGI?
-32- How should I set up my tape drive so tar's 'r' and 'u' options
work?
-33- What do I do when I can't read a tar tape made on another system?
-34- Why can't I write a tape on my DEC DAT drive and read it on my
SGI?
-35- How can I recover a partially overwritten tar tape?
-36- When and how should I clean my tape drive?
-37- How can I eject a jammed tape or CD?
-38- Can I use a non-SGI CD-ROM on my SGI?
-39- Why can't Joe User eject his CD-ROM?
-40- How can Joe User mount and unmount his MO disk?
-41- Why do SGI SCSI controllers have host ID 0 instead of the usual
7?
-42- What about Syquest removable media drives?
-43- EVERYTHING ELSE
-44- How long can my monitor/keyboard/mouse cables be?
-45- How fast is the Indigo parallel port?
-46- What are the differences between the Indigo R4000 and Indigo2?
-47- What high speed interfaces are available for Onyx?
-48- Why doesn't my modem work?
-49- What mice can I use with my Indigo or Indigo2?
-50- What mice or trackballs can I use with my Onyx?
-51- What about uninterruptable power supplies?
----------------------------------------------------------------------
Subject: -1- GENERAL INFORMATION
Date: 09 Jan 94 00:00:01 EST
The next few items discuss general questions about hardware.
------------------------------
Subject: -2- Where can I get a copy of SGI's Periodic Table of the
Irises?
Date: 10 Dec 93 00:00:01 EST
SGI Direct (see the misc FAQ for phone numbers) and your friendly
neighborhood salesbeing are guaranteed to have the latest.
Nonetheless, the misc FAQ lists the locations of FTPable Postscript
versions under "What are some related network-accessible
documents?".
------------------------------
Subject: -3- What third-party vendors sell thus-and-such for SGIs?
Date: 17 Feb 94 00:00:01 EST
Look in viz.tamu.edu:/pub/sgi/lists/3rd-party for lists of third-
party disks, memory, magneto-optical drives and general vendors.
------------------------------
Subject: -4- Where can I get used SGI machines?
Date: 18 Feb 94 00:00:01 CST
The SGI Systems Remarketing group makes used SGI machines available
to sales representatives. If you want to buy a used SGI machine, ask
your local sales rep or call SGI Direct (see the misc FAQ for phone
numbers).
wgbhres@world.std.com (Boris Levitin) lists some other remarketers:
Concorde Groupe 800-437-8621, 404-423-0070
Concorde Groupe, fax 404-426-8130
Falcon Systems, Jeff Geiger 800-326-1002
Minicomputer Exchange, John McFarland 408-733-4400
R-Squared, Tony Sciacca 800-777-3478
Security Computer Sales 612-227-5683
Sun Valley Technical Repair, Joe Ferris 408-224-6261
X-Systems, Jon Nies 800-886-5343, xsys@xsys.com
X-Systems, fax 303-443-7440
XS International 404-874-1212
------------------------------
Subject: -5- What is my old SGI machine worth?
Date: 26 May 93 00:00:01 CST
Thanks to Thomas Sippel-Dau <cmaae47@imperial.ac.uk> for this
summary:
Since computer technology has been improving so rapidly, this is
difficult to answer generally. But you can take the following
approches to get somewhere near a realistic estimate.
1. The Book Value.
This assumes the computer is an investment object which is written
down over a certain time. At the end of this time it is assumed that
the residual value will pay for scrapping the object, so you do not
have to pay someone to take it away. About 5 years seems reasonable
for computers.
Value the current value
Price the original price
n the age of the machine in months
p depreciation rate 1.6% (for 62.5 months useful life)
1.1 Linear method: Value = Price * ( 1 - n * p )
1.2 Degressive method: Value = Price * ( 1 - 2 * p ) ** n
In the first 4 years the degressive method will give lower values.
Once the degressive monthly depreciation is lower than the linear
one, you should sell the machine and buy a new one, otherwise you pay
more tax than you need to (talk to your accountants first, they
should know the exact depreciation rate and method).
2. Comparative method.
Get the new price of a similar current machine. Multiply the current
price by any usefulness multipliers. For example:
An Indigo R3000 server costs $8000 (N.B. NOT the real price)
An Iris 4D/25 is about half the speed of it
Then the current value of the 4D/25 cannot be more than $4000
regardless of what the book value says.
For this you must strip or enhance the machine to a current
standard.
Say you take the price of an Indigo with 432 disk Mbyte and 16 Mbyte
memory to assess the residual value of a 4D/25 with eight Mbyte
memory and 330 Mbyte hard disk. You will arrive at the price after
you have upgraded the the 4D/25 to 16 Mbyte.
Since both machines are not very useful (stand alone) with so little
disk space, you can allow for the difference in disk space when you
calculate the price of the whole running system.
For this method the old system must be able to run current software
usefully. A system that does not run current software has no value,
but see below.
You should also take account of the maintenance cost for about three
years, which is when a system you buy now would be due for
replacement according to the book value method.
3. Components and options.
You can view the system as an assembly of useful parts, such as
monitor, keyboard, disk drives, system box, electronics module. If
you have extra memory or disks (over and above the currently useful
minimum), you can value them at about 80% of the price you currently
have to pay third party suppliers.
4. Residual use value.
If you can find a dedicated use for an old general purpose machine,
then this could give you a final number. However, you need to allow
for any work you have to put in to get to that state, and to keep the
system there. You will also find that only reasonably large
organisations have such dedicated uses.
Finally, a word about maintenance:
If you have one system only, and you cannot afford to lose it, you
need to take maintenance, regardless of how much it is. From about 5
systems you can save yourself maintenance if you can afford to lose
the odd system and load its uses onto the remaining ones. But
remember that rescheduling people often meets resistance, and keeping
people idle because of a system failure is extremely expensive.
------------------------------
Subject: -6- What about my IRIS 2000 or 3000?
Date: 27 Feb 94 00:00:01 EST
Look in the misc FAQ for pointers to the IRIS 2000/3000 mailing list
and FAQ (the latter under "What are some related network-accessible
documents?").
------------------------------
Subject: -7- Should I shut off my Iris at night?
Date: 01 Jul 94 00:00:01 EST
(Home users often ask this.) No, you should not. The hardware is
designed for continuous use, and IRIX schedules cleanup tasks for the
early morning. (See the cron(1M) and crontab(1) manpages and the
files in /usr/spool/cron.) Disks, tapes, CD-ROMs etc. consume little
power when idle and should NEVER be turned off or on (or connected or
disconnected) when the system is running.
However, turning off your *monitor* will save power and prolong its
life.
------------------------------
Subject: -8- How fast is my R4000 or R4400 machine?
Date: 30 Apr 94 00:00:01 EST
Eric Williams <williams@agomoda.asd.sgi.com> reveals all:
It is confusing to spec the clock frequency for the R4000 and R4400
because they are so flexible. There are four interesting numbers:
- internal clock
- external clock
- secondary cache access cycle
- SYSINT frequency
Let's start by specifying the processor internal frequency. e.g. 150
MHz. All other frequencies are specified with respect to this one.
For programs that get good primary cache hit rates this number will
determine the performance.
The clock input to the R4400 (i.e. the crystal you buy) is always
half the internal frequency. In this case 75 MHz. This is generally
the number used by the chip manufacturers, to specify the speed of
the part. However from a system point of view, it is the least
visible to the user, and therefore IMHO the least interesting.
The secondary cache read and write access cycles are programmable in
terms the internal clock frequency (e.g. 150 MHz cycles). This
allows you to trade off the cost/speed of secondary cache rams with
system performance. When upgrading from 100 MHz to 150 MHz you can
either keep the same rams and increase the SCache access cycle or
install faster rams and keep the number of cycles constant. The
first option keeps the cost to a minimum while the second maximizes
performance.
Finally the interface that talks to the system (SYSINT) can run at a
programmable fraction (1/2, 1/3, ...) of the internal frequency. For
the example 150 MHz processor, this could be 75 MHz, 50 MHz, etc.
This puts an upper limit on the bandwidth to memory and affects some
latency parameters. Typically you would program the system interface
to run synchronously with the memory controller.
From what I've heard here about the Indy R4400 upgrade (I'm not
involved with it) I think you could say the following:
- the internal clock (primary cache, instruction execution, etc)
increases from 100 MHz to 150 MHz
- the clock crystal increases from 50 MHz to 75 MHz
- the secondary cache access times stays the same in absolute
terms (but increases in terms of internal clock cycles)
- the system interface to memory stays at 50 MHz (100 MHz div 2, vs.
150 MHz div 3)
BTW, the Indy upgrade example illustrates why IMHO the 75 MHz
external frequency of the R4400 is not an interesting number to
quote. Performance of real programs will be determined by the
internal 150 MHz clock, the secondary cache timing and the system
interface/memory speed, not the 75 MHz external clock.
------------------------------
Subject: -9- What is the IP number of each SGI model?
Date: 13 May 94 00:00:01 EST
There are two different IP numbers, one referring to the hardware and
one to the software (kernel configuration). The latter is what you
see when you type 'hinv'. Here is a table of both numbers:
HW IP SW IP Model CPU Speed
----- ----- -------------------- ----- -----------
IP2 IP2 IRIS 3000 68020
IP4 IP4 4D/50, 4D/70 R2000 12.5MHz
IP4.5 IP4.5 4D/80, 4D/85 R2000 16MHz
4D/60 R2300
IP5 IP5 4D/1x0 R3000 16.7MHz
IP6 IP6 4D/20 R3000 12.5MHz
IP10 IP6 4D/25 R3000 20MHz
IP7 IP7 4D/2x0 R3000 25MHz
IP9 IP9 4D/210 R3000 25MHz
IP13 IP7 4D/3x0 R3000 33MHz
IP15 IP7 4D/4x0 R3000 40MHz
IP12 IP12 4D/30, 4D/35, Indigo R3000 30-36MHz
IP17 IP17 Crimson R4x00 50 or 75MHz
IP19 IP19 Onyx, Challenge R4x00 50 or 75MHz
IP20 IP20 Indigo R4000 R4x00 50 or 75MHz
IP22 IP22 Indigo2 R4x00 50 or 75MHz
IP24 IP22 Indy R4x00 50 or 75MHz
The missing numbers were used for machines that were not released.
R4x00 machines can be 50 MHz R4000s or 75Mhz R4400s. 'hinv' reports
twice that in recent versions of IRIX; see the previous question for
an explanation. We use the smaller number here for consistency.
------------------------------
Subject: -10- MEMORY
Date: 09 Jan 94 00:00:01 EST
The next few items discuss adding memory.
------------------------------
Subject: -11- Can I mix 1MB and 2MB SIMMS in my 4D/20 & 4D/25 Personal
IRISes?
Date: 20 May 93 00:00:01 CST
From PIPELINE March/April 1992, page 18:
You can use either 1MB or 2MB SIMMs in these systems. If you mix 1MB
and 2MB SIMMs, all sixteen memory slots must be filled.
------------------------------
Subject: -12- Can I add 4MB SIMMS to my 4D/20 or 4D/25 PI?
Date: 19 Jun 94 00:00:01 EST
The short answer is "maybe". Read on.
Thanks to Michael Portuesi <portuesi@tweezers.esd.sgi.com> for this
helpful summary:
The 4D/2* has 16 memory slots. You get access to them by removeing
the right plastic cover and the metal shield underneath (box seen
from the front). The slots are in the upper, left corner (box now
seen from the right).
The slots have to be populated by SIMMs (some kind of industry
standard). I think 80 or even 100ns is allright, but take a look at
the speed of your own SIMMs.
SIMMs should always be mounted in groups of four. In a plain 8MB
4D/20 you have eight 1MB SIMMs. They are placed in slots A and B in
this figure:
ABCD ABCD
ABCD ABCD
If you upgrade to 16MB using eight more 1MB SIMMs you simply insert
the new SIMMs in slots C and D. If you are going to mix different
SIMMs you should always have the the same type of SIMM in slots with
the same letter.
As far as I know, the SGI 32MB memory upgrade is sixteen 2MB SIMMs,
and they are mounted in all the slots. Now, I have been told (but
haven't tried it) that it is possible to mix 1 and 2MB SIMMs. The
important point is that the 2MB SIMMs should be in the lowest
numbered slots. To get 24MB you should populate the slots as shown
(signatures are, 1 = 1MB SIMM, 2 = 2MB SIMM, 4 = 4MB SIMM, . = empty
slot):
2211 2211
2211 2211
The good news is that you can get 4MB SIMMs from third-party vendors
outpricing the 2MB SIMMs available from SGI. To get 32MB you mount 8
4MB SIMMs like this:
44.. 44..
44.. 44..
The bad news is that you cannot mix 4MB SIMMs with 1 or 2MB SIMMs
(leaving a lot of spare SIMMs) and even worse, not all 4MB SIMMs will
function properly.
Among the "good" SIMMs are those from Toshiba. They should look
something like this (information I got from a news article posted by
Chris Miller <eagle!news@ucbvax.berkeley.edu>):
module ID tags: chip numbers:
-------------- --------- TOSHIBA
| TOSHIBA | | 9025AAA | TC514100J-80
| THM94000S-80 | | JAPAN | JAPAN 9020HDK
-------------- ---------
Among the "bad" SIMMs are those from Hitachi:
chip numbers:
JAPAN R200
9026 2NN
HM514100JP8H
Other memory configurations that we have tried are (0 = empty slot, 1
= 1MB SIMM, 2 = 2MB SIMM, H = 4MB Hitachi SIMM, T = 4MB Toshiba
SIMM):
1100 1100 Came up as 8MB (correct)
1100 1100
1111 1111 Came up as 16MB (correct)
1111 1111
TT11 TT11 Came up as 64MB (wrong)
TT11 TT11
T000 T000 Came up as 16MB (correct)
T000 T000
TT00 TT00 Came up as 32MB (correct)
TT00 TT00
HH00 HH00 Came up as 0MB (wrong!!)
HH00 HH00
TH00 TH00 Came up as 32MB (correct)
TH00 TH00
TTH0 TTH0 Came up as 48MB (correct)
TTH0 TTH0
TTHH TTHH Came up as 64MB (correct)
TTHH TTHH
11TT 11TT Comes up as 16MB
11TT 11TT
It appears as though the machine checks the first bank of chips (port
0) to determine the chip size and assumes that the rest are the
same. The Hitachi 4MB SIMMs are NOT correctly detected.
It is important that the 4MB SIMMs in slot A are 'good'. Then you are
free to use "bad" 4MB SIMMs in the rest of the slots (this is my
experience), and it is possible to upgrade to 64 MB populating all
the slots with 4MB SIMMs.
When you do the actual seating of the SIMMs you should take
precautions (wear a static strap, work on a static pad) not to damage
the memory. Sometimes you will have to reseat a module. If a SIMM
is not properly seated it will probably show up on the diagnostics
terminal (if you have one attached) during power on.
After a succesful power on you should enter the PROM monitor and
issue the 'hinv' command. This should tell you how much memory you
have (or how much the 4D/2* believes it has). If this is correct you
are ready to boot.
Dave Olson <olson@sgi.com> adds: [The "good" vs. "bad" SIMM
business] is a PROM bug. We had a fix, but that PROM never
released. We didn't have 4 MB SIMMs when the last shipped prom
released. We read a memory location with the 4M SIMMs before we
initialzed it. SIMMs that power up all 1's work; those that power up
all 0's require a reset or two (by then the memory was initialized).
The Toshiba simms worked once; I've heard that current 4M Toshiba
simms may not.
The moral of the story: many people do fine with 4M SIMMs in their
4D25s, but don't buy them without a money-back guarantee.
------------------------------
Subject: -13- How many 4MB SIMMS can be put into an Indigo?
Date: 20 May 93 00:00:01 CST
One (1) set. Says Dave Olson <olson@sgi.com>: Due to a design flaw,
only one set of 4MB SIMMs (16 MB per bank) can be used in an R3000
Indigo, 4D/30 and 4D/35. This limitation doesn't apply to the 2 MB
or 8 MB SIMMs.
------------------------------
Subject: -14- How can I find a bad SIMM?
Date: 20 Feb 94 00:00:01 EST
Articles in the Mar/Apr 92 and May/Jun 93 Pipelines describe how to
find bad SIMMs in Personal Irises. The PROM diagnostics on Indigos
and newer can find them for you.
------------------------------
Subject: -15- Why does my system tell me I need a revision C Memory
Controller (MC) chip?
Date: 30 Apr 94 00:00:01 EST
Dave Olson <olson@sgi.com> explains: Long, long story. Short
synopsis: if you don't get memory errors, don't worry about it.
Slightly longer: A number of vendors' 16 Mbit chips had a bug in
them. We found it, and they agreed it was their bug, but they were
looking at a long, long DRAM spin time, so we worked around it in a
new rev (rev C) of the memory controller. The symptom was primarily
parity errors; this could be confused with the other parity error
problem we have, thus the warning message in 5.2.
At least some of the vendors that had the problem should have fixed
DRAM shipping by now, which is not to say that SIMMs you buy now have
the new DRAMs on them. Not all vendors had the problem.
------------------------------
Subject: -16- MONITORS AND VIDEO HARDWARE
Date: 09 Jan 94 00:00:01 EST
The next few items discuss monitors and video hardware.
------------------------------
Subject: -17- My monitor is maladjusted in some way. How to fix it?
Date: 27 Feb 94 00:00:01 EST
Get these handy writeups on monitor adjustment:
viz.tamu.edu:/pub/sgi/hardware/adjusting-your-monitor
viz.tamu.edu:/pub/sgi/hardware/adjusting-your-monitor-II
------------------------------
Subject: -18- Can I have 2 graphics displays on my Indigo?
Date: 18 Feb 94 00:00:01 CST
The Dual Headed IRIS Indigo with Entry Graphics (W-RPC-DH) sounds
like what you want. It has two Entry Graphics subsystems and two 16"
monitors. Contact SGI Direct (see the misc FAQ for phone numbers)
for more information.
Starting with Irix release 5.1.1.2, there is also support for
dual-head configurations on Indigo-2's. Both heterogeneous
(Extreme-XL) and homogeneous (XL-XL) hardware combinations are
possible.
------------------------------
Subject: -19- What do I need to do stereo on an Onyx/RE2?
Date: 14 Jun 93
Paul Spencer <spencer@hailwood.asd.sgi.com> illuminates us with: You
just need the shutter glasses (and the emitter, which comes with the
glasses). This is available as a kit from SGI. The standard SGI
RealityEngine monitor can do stereo; you don't need a special CRT.
Demo programs and sample source code are part of every IRIX release.
------------------------------
Subject: -20- Can I use my SGI monitor on my PC?
Date: 24 Aug 94 00:00:01 EST
Rick McLeod <mcleod@esprit.esd.sgi.com> writes: This depends on the
SGI monitor. PCs want multifrequency/ multiscanning/multisyncing
monitors. Earlier SGI platforms supplied fixed frequency or dual
scan mode monitors. These will not work on PCs. Some current SGI
machines (Indy, Indigo2, Onyx) ship with multiscan monitors. These
will most likely work with a PC, but make sure that the monitor gets
the proper sync signal.
Clinton Keith <clint@art.ray.com> adds his implementation details:
The GDM-17E11 works on my PC with a Diamond Speedstar 24x. I used a
VGA connector that brought out the RGB V and H sync lines from the
24X into BNC connectors (commonly avaliable at a local computer
store). I connected the V sync H sync and Green lines together and
connected this line and the Red and Blue lines to a BNC-to-DB13W3
connector (bought a workstation supply vendor) which went to the
monitor.
I then set up the 24X to provide -/- sync voltages and selected the
highest vertical and horizontal scan rates I available.
Unfortunately, the monitor refused to display 640x480 (pride?) but
did well at 800x600, 1024x768 and 1280x1024. There was a slight
greenish tint to the black areas of the screen. It seems as though
connecting the sync lines to the Green may have added a DC bias, but
the effect is minor.
------------------------------
Subject: -21- Can I use my PC monitor on my SGI?
Date: 28 Jan 94 00:00:01 EST
Rick McLeod <mcleod@esprit.esd.sgi.com> writes: The PC monitor must
be able to handle a 1024x768 non-interlaced signal to be used with
Indigo starter graphics or Indy. Most of SGI systems operate at
1280x1024 non-interlaced. Most PC monitors will not be able to deal
with the scan rates required to display a stereo image.
------------------------------
Subject: -22- What video formats, scan rate, etc. do SGI monitors
support?
Date: 20 Feb 94 00:00:01 EST
It depends on the monitor. See the Sep/Oct 93 Pipeline (and a
correction on p. 26 of the Nov/Dec 93 Pipeline) for a tabulation of
the characteristics of most types of SGI monitors.
------------------------------
Subject: -23- How can I set my Indy to use 1280x1024 pixels on a third
-party monitor?
Date: 19 May 94 00:00:01 EST
As root, do 'nvram monitor h' and reboot. See 'man 2 sgikopt' for
details.
------------------------------
Subject: -24- STORAGE DEVICES
Date: 09 Jan 94 00:00:01 EST
The next few items discuss storage devices. Tapes, mostly.
------------------------------
Subject: -25- What do all these SCSI technical terms mean?
Date: 12 Feb 94 00:00:01 EST
Look in rtfm.mit.edu:/pub/usenet/comp.periphs.scsi/ for the
comp.periphs.scsi FAQ.
------------------------------
Subject: -26- How many SCSI devices can I have on an Indigo?
Date: 26 May 93 00:00:01 CST
You can have 7 SCSI devices, and as long as you have clean cabling,
and one (and only one!) SCSI terminator at the end of the chain, and
keep total cable length under 6 meters, there should be no problems,
as far as the Indigo's bus itself goes.
On an Indigo2, you can have 7 devices on the external SCSI bus, and
up to 3 devices on the internal bus.
------------------------------
Subject: -27- How do I install external SCSI disks on my SGI?
Date: 02 Feb 94 00:00:01 CST
The basic procedure is to use 'fx' to format and label the drive (the
label contains the partition layout), use 'mkfs' to create the empty
filesystem, create the mount points and put the proper entries into
/etc/fstab. The IRIX Site Administrator's Guide describes this in
detail.
The graphical Disk and File tool assumes you bought your drive from
SGI, in which case the 'fx' and 'mkfs' parts have already been done.
It also assumes you want to use the entire drive as a single
partition.
------------------------------
Subject: -28- What kind of DAT drive does SGI sell for the Indigo?
Date: 26 May 93 00:00:01 CST
The Indigo DAT drive is an ArDAT Python 4320.
The drive SGI sells is completely standard 3.5" form factor hardware
(no compression), but has firmware that so far ARDAT is selling only
to SGI to provide audio over SCSI support, and to fix some bugs.
------------------------------
Subject: -29- Can I use a 3rd-party cartridge tape drive on my Indigo?
Date: 26 May 93 00:00:01 CST
The Tandberg and Archive QIC24 and QIC-150 drives both work just fine
on the Indigo (both come in external versions), as do the Wangtek and
Tandberg QIC-1000 drives (as of this quarter, and 4.0.5F or later).
------------------------------
Subject: -30- Which Exabyte drives work with SGI systems?
Date: 26 May 93 00:00:01 CST
Dave Olson <olson@sgi.com> says: First, the 8200 (2.3 Gb). The
original version we qualified was 100% stock from Exabyte. It had
some problems on the ESD machines at power on, because of the
somewhat non-standard way it handled the send-diag SCSI command. The
current rev (252T) we ship is also standard firmware from Exabyte (to
the best of my knowledge), and fixes that problem, and is also more
robust in the face of servo problems.
The 8500 (5 Gb) isn't fully qualified (by SGI) yet, and there is some
argument over whether we will ask for custom firmware; I think we are
definitely slanting towards standard firmware. The gotcha here is
that Exabyte has released so many firmware revs for the 8500, that
the word 'standard' is somewhat of a joke. I've lost touch with that
effort a bit, so I don't know what firmware rev we are currently
working with.
4.0.1 is the first IRIX release with support for the 8500, earlier
releases will work to varying degrees with different 8500 firmware.
------------------------------
Subject: -31- How to connect my 3rd-party tape drive to my SGI?
Date: 08 Oct 94 00:00:01 CST
Only part of the voluminous literature on the topic may be found at
viz.tamu.edu:/pub/sgi/hardware/3rd-party-DAT-drive
viz.tamu.edu:/pub/sgi/hardware/exabyte-8505-setup
viz.tamu.edu:/pub/sgi/hardware/exabyte-howto-for-sgis
------------------------------
Subject: -32- How should I set up my tape drive so tar's 'r' and 'u'
options work?
Date: 09 Jan 94 00:00:01 EST
Sara Kunz <kunz@binah.cc.brandeis.edu> writes: Use the variable
block size tape devices. These are called /dev/rmt/tps0d#nsv and
/dev/rmt/tps0d#nrnsv, where '#' is the tape's SCSI device number. If
the tape drive is properly attached (it should appear in 'hinv's
listing), saying '/dev/MAKEDEV tps' should create the devices for
you. If the tape drive in question is the tape drive with the lowest
SCSI ID, '/dev/MAKEDEV tapelinks' will link the appropriate devices
to /dev/tape and /dev/nrtape. Note that appending is physically
possible only on 9-track and DAT tapes.
------------------------------
Subject: -33- What do I do when I can't read a tar tape made on
another system?
Date: 04 May 94 00:00:01 EST
Glenn Randers-Pehrson <glennrp@BRL.MIL> says:
You may be trying to read a non-byte-swapped tape on a byte-swapped
device, or vice versa. Tar tapes written on SGI's QIC cartridge
drive, using the default device, /dev/tape, are in byte-swapped
format. Sun tapes are usually not byte-swapped. On the IRIS, you can
read non-byte-swapped tapes with
tar -xvf /dev/tapens
and you can write non-byte-swapped tapes destined for a Sun with
tar -cvf /dev/tapens [directory_or_filename[s]]
On the SUN, you can read byte-swapped tapes with
dd if=/dev/rmt0 conv=swab | tar -xvf -
Read the tar(1) (DIAGNOSTICS section) and tps(7M) manpages for the
gory details.
DAT tapes may have an additional problem: SGI DATs have a default
blocking factor of 512 and HP DATs have a maximum blocking factor of
128. You can either rewrite your tape on the SGI with
tar cvbf 20 /dev/tape files
and read it on the HP (or whatever) with
tar xvbf 20 /dev/tape
or you can use 'dd' to translate like so,
dd if=/dev/tape ibs=512b of=- obs=20b | tar xvf -
where '512' is whatever blocking factor you used to write the tape.
------------------------------
Subject: -34- Why can't I write a tape on my DEC DAT drive and read it
on my SGI?
Date: 03 Dec 94 00:00:01 EST
DEC DAT drives use hardware compression by default, and SGI DAT drives
can't handle that. Turn it off.
Furthermore, some SGI DAT drives hang when trying to read a hardware-
compressed tape, instead of saying "incompatible media" as they
should. This is fixed in recent firmware; call the TAC to get an
upgrade.
------------------------------
Subject: -35- How can I recover a partially overwritten tar tape?
Date: 10 Dec 93 00:00:01 EST
People often overwrite the beginning of large tar archive, leaving
the first bit of the tape overwritten and the rest presumably intact.
This is usually NOT recoverable.
However, if you're feeling lucky, you might (says Dave Olson
<olson@sgi.com>) try something like 'mt fsf 4; mt bsf 2; tar xe' or
'mt fsf 4; mt bsr 2; tar xe'. You might also try 'tar cv foo', where
'foo' is slightly bigger than what you overwrote the archive with the
first time, and pull the plug on the tape drive before it writes the
EOF. Then power it back up and try 'tar xe'.
If this sounds unlikely to work, you're right. Don't let it happen;
use the write protect tab.
------------------------------
Subject: -36- When and how should I clean my tape drive?
Date: 20 Feb 94 00:00:01 EST
9-track and QIC drives should be cleaned every 8 hours of use, or
more often when using many new tapes, and certainly when the number
of "recoverable errors" gets uncomfortably high. See the Nov/Dec 91
Pipeline or the "IRIS Software Installation Guide" for a detailed
cleaning procedure. Briefly, shut the drive down and swab the head
with isopropanol and a lintless cloth.
8mm and DAT drives need to be cleaned every 30 hours of use, using a
commercial cleaning tape according to the instructions.
------------------------------
Subject: -37- How can I eject a jammed tape or CD?
Date: 05 May 94 00:00:01 EST
Shut down your system nicely, hold down the drive's eject button and
turn the drive's power (or, for internal drives, the system's power)
off and on. See also
viz.tamu.edu:/pub/sgi/hardware/ejecting-jammed-tape.
------------------------------
Subject: -38- Can I use a non-SGI CD-ROM on my SGI?
Date: 14 Feb 94 00:00:01 EST
4D20, 25, 70, 80 and 85s and most Power Series machines can boot only
from SGI CD-ROMs. Older machines can boot only from a local tape
drive or over the network. Newer machines (4D30 and 35s, Indigos,
Challenges, Onyxes, Indys, etc.) have smarter PROMs and can boot from
at least some third-party CD-ROMs, for example the Sony and Toshiba
drives intended for Suns. The rest of this entry discusses what
qualifies a drive for 4D30s and later.
Dave Olson <olson@sgi.com> of SGI says, The basic requirement for
Indigos is that the drive be set to use a 512 byte block size. Since
Indigos don't reset the SCSI bus on reboot or halt, you *might* be
able to boot your machine in some other way, set the CD-ROM's
blocksize with a devscsi program while the system is up and then
install from it, but I won't swear to it. Late R4K Indigos, Indys,
Indigo2s, and Onyx/Challenges all know how to set the block size if
the drive identifies itself as a CD-ROM, reports the block size as
something other than 512 bytes in the block descriptor and accepts
the new block size in the block descriptor.
Rob Silvers <rsilvers@nynexst.com> reports that he has been
sucessfully using a third-party dealer's Toshiba TXM3401E1 on an
Indigo. It cost about $760. It is physically larger than an external
Apple or Next drive. It is double speed and handles multi-session
photo-CDs. 'cdromd', 'inst' and 'cdman' work, but he has not tried
to boot from it as of 12 June 93.
Bart Richards of Thunderstone Software <bart@thunderstone.com>
writes, The following minor surgery makes a run of the mill Toshiba
3401[B|E] CDROM drive SGI [Indigo] or Sun-compatible. I got it
straight from an anonymous Toshiba Tech. guy, and it worked for me.
There are two solder pads located on the circuit board at the back
right corner of the drive's aluminum housing when viewed from the top
with the SCSI connector facing away from you. These may or may not be
labeled as '0' & '1', but '0' is on the left and '1' is on the right
(or closest to the edge of the circuit board). The normal state for
these solder pads from the factory is for both of them to be closed.
With an Exacto Knife or soldering iron (whichever is appropriate for
the desired configuration), cut or solder these pads to match the
entries in the following table:
+++___++++++++__
|power SCSI |
'0' '1' O=CUT/OPEN S=SHORTED/SOLDERED | 01|
---------- |----------------|
S S Toshiba Default (2048 byte block) | |
S O 512 byte blocks | TOP |
O S SGI ( Bootable ) | OF |
O O Sun / Integraph | DRIVE |
| |
| |
| |
|________________|
DOOR
------------------------------
Subject: -39- Why can't Joe User eject his CD-ROM?
Date: 24 Feb 94 00:00:01 EST
- /usr/sbin/eject has the wrong permissions in IRIX 4.0.5H and IOP.
It should be setuid root. Say 'chmod 4755 /usr/sbin/eject' (as
root) to fix it.
- Someone may be cd'ed into the CDROM directory. Do 'fuser /CDROM' to
find the number(s) of the process(es) that are cd'ed there, and
kill them.
------------------------------
Subject: -40- How can Joe User mount and unmount his MO disk?
Date: 22 Jan 94 00:00:01 EST
cdromd (mediad in IRIX 5.x) doesn't understand MO disks. You need the
'mountmo' program, at viz.tamu.edu:/pub/sgi/hardware/mountmo.c.
------------------------------
Subject: -41- Why do SGI SCSI controllers have host ID 0 instead of
the usual 7?
Date: 24 Feb 94 00:00:01 EST
It's a controller chip default. It was left alone because it doesn't
matter much: host ID doesn't affect throughput, except perhaps on a
horrendously overloaded bus. However, drives whose ID is set by
jumpers are usually shipped with ID 7 (all three jumpers on), so you
can just plug one in to an ID 0 host.
------------------------------
Subject: -42- What about Syquest removable media drives?
Date: 08 Oct 94 00:00:01 EST
SGI's Bob Miller <kbob@sgi.com> has written an FAQ on using Syquest
drives with SGIs. A copy is at
viz.tamu.edu:/pub/sgi/hardware/syquest-on-sgi-faq.
------------------------------
Subject: -43- EVERYTHING ELSE
Date: 09 Jan 94 00:00:01 EST
The rest of the FAQ discusses things that didn't fit into
categories.
------------------------------
Subject: -44- How long can my monitor/keyboard/mouse cables be?
Date: 25 Feb 94 00:00:01 EST
Dave Olson <olson@sgi.com> writes,
SGI has (or had at one time) a 75 foot monitor cable on the price
list. With a decent cable, this is about as far as you can get
without getting pretty fuzzy; I've heard that with an extremely high
quality cable, you can get to about 100 feet. Your limits may vary.
EIA 423 should have no problems with up to 100 feet either, since the
mouse is at 4800 baud, and the keyboard at 600.
Will McCown <will@rhythm.com> adds,
We routinely extend the SGI video cables up to about 150' using high-
quality (Canare LV-61s) coaxial cables. For newer SGIs which use the
13W3 "D" connector instead of BNCs, adapters are available from
several sources including NuData (908) 842-5757 part number 6647.
The "PS/2 compatible" keyboards and mice used on the Indigo II, Indy,
etc. do not accept simple extension cords as well as the older
keyboard/mice. We have successfully extended these keyboards & mice
up to about 100', but beyond 150' they never work. The problem lies
in the high-impedance TTL-level signaling used. Beyond this distance
you can use an extender box made by Cybex (205) 430-4000, which is
designed to extend the IBM PS/2 keyboard and mouse.
Our method for making keyboard/mouse extensions is to buy 6' IBM PS/2
keyboard extension cables (male 6-pin mini-din one end, female 6-pin
mini-din on the other), and cut the connectors off of these cables
leaving about a 6-12" pigtail on each connector. We then attach
RJ-12 connectors (IDC type modular phone connectors) to the free end
of each pigtail. We then extend the cable using flat 6-conductor
phone cable, RJ-12 connectors, and "barrel" adapters. This may sound
like a lot of work but it is very quick to assemble, and requires no
soldering.
For really long runs, Rick McLeod <mcleod@esprit.esd.sgi.com> says,
Two companies provide long distance (up to a couple of thousand feet)
fiber optics extensions for keyboard, mouse and monitor:
Lightwave Communications (203) 878-9838
Meret Optical Communications (310) 828-7496
------------------------------
Subject: -45- How fast is the Indigo parallel port?
Date: 26 May 93 00:00:01 CST
Default rate is about 200 Kbytes/sec. This can be bumped up to at
least 400, and perhaps higher by changing the strobe length, assuming
the other side can handshake fast enough. See the plp(7) manpage.
------------------------------
Subject: -46- What are the differences between the Indigo R4000 and
Indigo2?
Date: 09 Jun 93 00:00:01 EST
Jamie Riotto <jamie@origami.esd.sgi.com> writes:
An Indigo R4000 has two daughter board expansions which use our
GIO-32BIS bus design. These cards are about the size of an index
card.
An Indigo2 has a 4-slot backplane design. All four slots have EISA
connectors so you can have a graphics-less server with four EISA
cards. Three of the slots have GIO-64 bus connectors, BUT ONLY TWO
CONNECTORS CAN BE USED SIMULTANEOUSLY!. Graphics board sets take up
one logical GIO-64 connection, but can take up more physical slots.
The current Extreme graphics takes up one logical GIO-64 connection,
but uses three slots. That means the other slot can be used for
either EISA or GIO-64 expansion. Note that since not all slots have
both EISA and GIO-64 connectors, you might have to shift the Extreme
graphics board set up or down a slot if you want to use the fourth
slot with GIO-64 expansion.
GIO-64 by the way is similar to GIO-32 but is twice as wide, uses a
different DMA protocol (pipelined), and used EISA form factor (with
the connector moved of course :-).
------------------------------
Subject: -47- What high speed interfaces are available for Onyx?
Date: 11 Jun 93 00:00:01 EST
Robert van Liere <robertl@cwi.nl> writes:
SGI have FDDI boards for the Onyx. These boards perform quite well
although the Indigo FDDI broad preforms slightly better. I'm not sure
about SGI ATM, although I guess all vendors are preparing for it.
FORE systems make ATM boards for the GIO bus. Maybe they have
something for the HIO as well.
FORE systems, Inc
1000 Gamma Drive
Pittsburgh, PA 15238-2940
412-967-4040
Fax 412-967-4044
info@fore.com
GIA-100/125A (100 Mbps GIO Bus)
GIA-100/175A (140 Mbps GIO Bus)
and Yechezkal-Shimon Gutfreund <sgutfreund@gte.com> adds:
Fore Systems, Pittsburgh PA, selles a 150Mbit/s ATM adapter card that
you can use to connect to their ATM switch (using multi-mode fiber).
------------------------------
Subject: -48- Why doesn't my modem work?
Date: 19 Nov 94 00:00:01 EST
Lots of reasons, but here are some of the most popular:
- You're not using hardware flow control. To do so, you MUST 1) use
the ttyf* devices, not ttyd* or ttym*, and 2) use a "hardware
handshake" 7-wire cable, which you can buy from SGI but usually
*not* from a Macintosh house. Look at the serial(7) manpage for
details.
- The modem is configured funny. Look at the configuration scripts in
/usr/lib/uucp/fix-* and see if there's one for your modem.
- /usr/lib/uucp/Permissions is wrong. /usr/lib/uucp/genperm will
generate Permissions entries for all /usr/lib/uucp/Systems
entries.
- IRIX 5.2 had several problems with serial I/O, flow control and PPP
interoperability. They are fixed in patch 151. Call the TAC.
------------------------------
Subject: -49- What mice can I use with my Indigo or Indigo2?
Date: 09 Jan 94 00:00:01 EST
Indigos need special Indigo mice. Replacement mechanical or optical
(take note, mechanical mice haters!) mice are available from SGI or
directly from Mouse Systems (510-656-1117).
Indigo2s can use PS/2 mice as per the pcmouse(7) manpage. Dave Yost
expands on this: The Indigo2 takes any industry standard mouse of
the variety variously known as "IBM PS/2", "Mouse Port" or "6-pin".
A PC serial mouse won't do, even with an adaptor, unless it is
claimed to work on a PS/2 through an adaptor. The Logitech "MouseMan
Cordless" mouse works for me.
------------------------------
Subject: -50- What mice or trackballs can I use with my Onyx?
Date: 01 Jul 94 00:00:01 EST
John Kraft <jfk@lycidas.engr.sgi.com> writes:
Unlike the Indigo and Indy (see above), Onyxes use a custom serial
mouse. If you'd prefer an optical mouse over the standard mechanical
mouse shipped with the system, call Mouse Systems (510-656-1117) or
Qualix (415-572-0200). If you'd like a trackball, call Mouse-Trak
(800-533-4822, email yvonne@mousetrak.com).
------------------------------
Subject: -51- What about uninterruptable power supplies?
Date: 08 Oct 94 00:00:01 EST
Get the UPS FAQ from navigator.jpl.nasa.gov:/pub/doc/faq/. See also
viz.tamu.edu:/pub/sgi/hardware/surge-protectors.
------------------------------
End of sgi/faq/hardware Digest
******************************
--
The SGI FAQ group sgi-faq@viz.tamu.edu
Finger us for info on the SGI FAQs, or look in viz.tamu.edu:/pub/sgi.
(2) - Moire Patterns
---------------------------------------------------------------------------
What causes those distracting moire patterns that can
be seen on some monitors?
I've been asked if the monitor or the computer can be adjusted
to remove them.
Sometimes degaussing (as in "hit the built-in degauss button)
works for us.
(3) - Disk problems on crashed system
---------------------------------------------------------------------------
We have an R4000 Indigo that crashed pretty hard last night. When I
rebooted it, it came up with the message:
No volume header on device: scsi()disk(1)rdisk()partition(1)/osloader.exe
Autoboot failed
I called user support, and they told me to re-install eoe1.sw.unix, which
I did. After doing that, upon reboot, I got the error message :
Unable to load bootfile: no such device
So I went into fx and did label/create/bootinfo to see if that would
work. And when I rebooted this time, I got the original error message
again.
Somebody has been playing with your nvram settings. Try stopping
at the PROM monitor, and give the command:
resetenv
then reset your netaddr to the correct IP address with:
setenv netaddr www.xxx.yyy.zzz
then try booting.
(4) - Forced Perfect Terminators
---------------------------------------------------------------------------
I remember some discussion quite a while ago about the different types
of active terminators. My question concerns the Forced Perfect
Terminators, are they better or worse than "plain" active terminators?
Are there any terminators that I should avoid?
The problem with FTP is that it can (in some circumstances) pull more
than the allowed 4 ma per signal. This can do bad things to some SCSI
controller chips. Some people have had success with it, but in general
it doesn't seem to help more than active termination. Given that
it violates the specs, I try to discourage people from using FPT.
(5) - Determining graphics mode
---------------------------------------------------------------------------
| I have just found an incompatibility between GL running on a 4D/210 running
| 4.0.5C, and an Indigo R4000 Elan running 4.0.5H. The getgconfig function
| does not exist on the older version. TAC says they cannot help and by the
| end of the year there *may* be a fix.
It is a new function, so of course won't be in older releases. Seems
unlikely to be 'fixed', since it isn't a bug.
| I wonder
|
| 1. Can I force the newer GL onto the older machine?
No.
| 2. Is there a solution I can demand to have now (we have full support on
| both machines) ?
No.
| 3. Is there a good workaround - I want to know whether I am in colormap or
| RGB mode and getgconfig seems to be the only way to tell me that ?
I'm pretty sure there is a much older method, although I don't remember
what it was, one of the graphics folks will hopefully post it.
Yes. Try getdisplaymode();
FUNCTION RETURN VALUE
The returned value for this function tells you which display mode is
currently active.
______________________________________________
|Symbolic Name | Display Mode |
|_____________________________________________|
|DMSINGLE color map single buffer mode |
|DMDOUBLE color map double buffer mode |
|DMRGB RGB single buffer mode |
|DMRGBDOUBLE RGB double buffer mode |
|_____________________________________________|
(6) - Printer port gets stuck
---------------------------------------------------------------------------
Has anyone experienced the printer port of a 4D/35 getting stuck for no
apparent reason? Zapping the daemons doesn't get it running, but a
reboot (not a power cycle) does work.
--- 1 ---
Sounds like the cable to the printer might be long enough to cause
problems, in that case. It should be no more than 2.5 meters; some
printers are more sensitive than others. Using a print buffer box
has helped some folks who just had to have longer cables (keep it
short on the SGI side).
--- 2 ---
I used to have problems with my 4D/35 when the printer would jam (a
frequent occurance with certain color printers). The attached program
(when run as root or suid root) will clear the port. It works for me,
but don't blame me if it explodes your CPU, erases your disk and
destroys your printer :)
-- cut here --
#include <sys/types.h>
#include <fcntl.h>
#include <sys/plp.h>
main()
{
int fd;
int retval;
setuid(0);
retval = system("/usr/lib/lpshut");
if(retval != 0) {
perror("error from lpshut command");
}
printf("Killing off processes using parallel port\n");
retval = system("/etc/fuser -k /dev/plp");
if(retval != 0) {
perror("error from fuser command");
}
if((fd = open("/dev/plp",O_RDWR)) < 0) {
perror("unable to open parallel port");
exit(-1);
}
/* reset the printer */
retval = ioctl(fd,PLPIOCRESET);
printf("Printer port reset\n");
/* start up the spooler again */
system("/usr/lib/lpsched");
printf("Printer scheduler restarted\n");
}
-- cut again --
Yes, toggling the reset line on the parallel port (which is what this
does) may help after things get stuck, but powercycling the printer
will do the same thing. In any case, that can be a drag for long
print jobs, and only treats the symptom, not the cause.
(7) - Maximum Memory capacity
---------------------------------------------------------------------------
>You can install 1, 2, or 3 banks of SIMMs. Each can be 4, 8, 16, 32, or 64
>MB with current DRAM sizes (the latter 2 require 16 Mb chips).
>Max memory is therefore 384 MB (more than 256 will be ignored until
>5.1 and later). Min memory is 16 MB.
I'm sorry but this still isn't clear to me...
Okay, the minimum is (1) bank of (4) 4MB SIMMs whichs equals 16MB, yes?
So, would not the maximum thus be (3) banks of (4) 64MB SIMMs which equals
768MB? But this value is 2x the 384MB maximum you state.
Also, do the 16MB SIMMs exceed the 18-piece chip count you cautioned us
about in a previous posting? Or maybe I'm just off today on all this.
There aren't enough address lines for that, so 512 is the theoretical
max the system can support (yes, 512, not 384).
Besides, I had a typo (I got carried away!). 32 MB per SIMM is the
max (no more than 18 DRAMs per SIMM, due to capacitive loading
issues). Sorry. In *theory*, the system could have 512 MB with 64Mbit
chips and 64 MB per SIMM, but it will be quite a while before we know
if that will really work.
The 16 and 32 MB SIMMs are 16 Mbit chips; using 4 Mbit chips
would be too much of a load.
(8) - Disk Striping Questions
---------------------------------------------------------------------------
I have a few questions about striping disks on an SGI Challenge.
Is there any documentation on how to optimize a striped disk, such as
how to calculate the correct step size for the lvtab, the best buffer
size for reading/writing to the stripe, the use of direct i/o with
a stripe, etc?
There really is no such thing as an optimal stripe. It depends on just
what you want to do, so you need to experiment.
Does anyone have any experience with using direct i/o for writing to
a striped disk and if so what if any performace gain was seen?
There is some gain, since the advantage of direct i/o is direct dma
to/from the user program, rather than going through the buffer cache
and copying the data.
Are there any good benchmarks for determining max throughput to/from
a striped disk?
Not really. There are a number of i/o benchmarks, but they all have
their flaws (including those we use internally). Your own apps are
really the best benchmark.
(9) - Seagate ST42100N configuration
---------------------------------------------------------------------------
I'm probably going to have to contact the vendor, but I'm hoping someone
will have an answer for me over the weekend....
I bought a drive tray & 4 Seagate 5.25" 2.1GB SCSI drives (model ST42100N)
for my 4d/340, but the remote SCSI ID switches on the tray aren't connected
to the drives. Can someone tell me how to connect them, or failing that,
just describe the pinout for the model ST42100N SCSI ID connector pins?
Looking at the rear & bottom of the Seagate drive:
SCSI ID etc.
------------ ------------------------- --------
|::::::::::| | SCSI data connector | |power |
------------ ------------------------- --------
|
|
------ exploded view ----
|
2 4 6 8 A C E G I K (total of 10 pairs of pins)
1 3 5 7 9 B D F H J
- pins 1 & 2 are currently jumpered
- pins D & E are currently jumpered
I'm fairly sure the last 6 pins set the SCSI ID, since the remote SCSI ID
switches are 6-pin connecters, but the various combinations I've tried have
come to naught so far. Actually, the "6-pin" remote SCSI ID connectors are
a pair of 3-pin connectors, so there's more than a few possible combinations.
And I haven't tried any of the first 14 pins yet. ;-(
--- 1 ---
According to my ST41200N docs (I havn't opened up my machine to check)
there are 8 (eight) pin pairs to the left of the SCSI connector.
Numbered left to right, starting with 1 (one), pairs 3, 4 and 5
control the SCSI ID of the unit. Pair 5 is the low bit.
--- 2 ---
My ST42100N drives have 10 pin pairs to the left of the SCSI connector.
The drive ID pins ended up being the 3rd, 4th, and 5th pin pairs,
counting from the left side of the drive, when viewing from the
rear, which seems to match what Bill is saying above (Thanks Bill!!).
Regardless, I'd have spent days trying to figure it out if I hadn't
received a specsheet via email. Once again, Usenet beats a call
to technical support hands down!! ;-)
Thanks loads to Ryan J Snodgrass <rsai+@andrew.cmu.edu> for his
speedy reply with the following:
ST-42100N Wren 9 FH SCSI-2 Fast
Z Synchronous Spindles option DC
3 Power
3 UMMMMMMMMMMMMMMMMMMMMMMMMMMMMM8 /DDDDDDDDD\
MMMMMMMMPMWMAMMMMMMMMM5:SCSI:Cable:::::::::::::::::1FM5 0 0 0 0 FMM
ZD? ZDAD? TMMMMMMMMMMMMMMMMMMMMMMMMMMMMM> @D5DGDGD12Y
3o3o o o o o o o3o+o3 ZDDDDDD1 ZDDDDDD1 ZDDDDDD1
EoEo o o o o o o3o-o3 @DDDDDDY @DDDDDDY @DDDDDDY
@1Y 4 2 1 @DDDY Terminator SIPS
3 3 DDBDD 3 3 3
3 3 3 3 3 @D Motor Start Delay (16 secs * ID)
3 3 3 3 @DDD Parity check enable
3 3 3 @DDDDD Motor Start option enable
3 3 @DDDDDDDDD Drive ID's, ID 0 (none) if only SCSI device
3 @DDDDDDDDDDDDD Terminator power to the Bus (vertical)
@DDDDDDDDDDDDDDE Terminator power from Drive, default (vertical)
3 Terminator power from Bus (lower horizontal)
LED
ZDDD? (Viewed from front of drive) Z GND
3 0 3 3
MMMMOMMMOMMMMMMMMMMMMMPMWMAMMMMMMMMMMMMMMMMMMMMMMMMMMXMMMMMMMMMMMM
o o o J6
pin-1 (+5v) ----o o o
3 3 3
Remote LED connection DDY 3 3
Write Protect Remote EDDDY 3
Switch cable connection 3 3
Factory Use Only DDDDDDY
ST-42100N
WREN 9 FH
UNFORMATTED CAPACITY (MB) ________________2,200
FORMATTED CAPACITY (xx SECTORS) (MB) _____1,900*
AVERAGE SECTORS PER TRACK (with spares)___96
ACTUATOR TYPE ____________________________STRAIGHT ARM
TRACKS ___________________________________38,595
CYLINDERS ________________________________2,573 (user)
HEADS ____________________________________15
DISCS (5.25 inch) ________________________8
MEDIA TYPE _______________________________THIN FILM
RECORDING METHOD _________________________ZBR RLL (1,7)
INTERNAL TRANSFER RATE (mbits/sec) _______20 to 31
EXTERNAL TRANSFER RATE (Mbytes/sec) ______10.0 Sync.
SPINDLE SPEED (RPM) ______________________3,600
AVERAGE LATENCY (mSEC) ___________________8.33
BUFFER ___________________________________256 Kbyte
Read Look-Ahead, Adaptive,
Multi-Segmented Cache
INTERFACE ________________________________SCSI-2 Fast
BYTES PER TRACK __________________________57,200 avg.
SECTORS PER DRIVE ________________________3,705,120
TPI (TRACKS PER INCH) ____________________2,150
BPI (BITS PER INCH) ______________________
AVERAGE ACCESS (ms) ______________________12.95
SINGLE TRACK SEEK (ms) ___________________2
MAX FULL SEEK (ms) _______________________29
MTBF (power-on hours) ____________________150,000
POWER REQUIREMENTS: +12V START-UP (amps) _4.5
+12V TYPICAL (amps) __1.5
+5V START-UP (amps) __0.8
+5V TYPICAL (amps) ___0.6
TYPICAL (watts) ______21
MAXIMUM (watts) ______58
LANDING ZONE (cyl) _______________________AUTO PARK
IBM AT DRIVE TYPE ________________________0 or NONE
* 512 bytes per sector, one spare sector per track,
two spare cylinders per unit.
Already low-level formatted at the factory.
--- 3 ---
Did you mean to say "ST41200N"? I'm looking at the ST42100N
INSTALLATION MANUAL sheet, and it shows ten (10) jumper pairs,
but as you said, the 3rd, 4th and 5th pairs starting from the
left determine the SCSI ID, with the 5th pair being the LSB.
Also, the 4th pair from the right, which the poster indicated
was set on his drive, is the "enable parity reporting" jumper,
which we also have set.
(10) - SCSI Timeout problems
---------------------------------------------------------------------------
>> The problem I have is that after a few transfers, the following
>>message appears in the console window:
>
>>dks0d1s0 (/): retrying request
>>sc0,1,0: cmd=0x2A timeout after 30 sec. Resetting SCSI bus.
>>[particulars: Indigo1, 405F, Integral SCSI ctrl Version WD33C93B, revision D]
--- 1 ---
There are several things that could be at fault. I am presuming that
you are using Single Ended SCSI.
First and foremost is that your SCSI cable lengthis too long. This is
common enough that you should really examine the length. Besides the
external cables you're using between your devices, remember the
lengths of the cable inside your peripheral boxes. The Max length on
a SCSI bus is supposed to be about 18 feet, but the machine takes up
some of that length electronically. I was told (by the SGI support
line) that the Challenge M, for example uses up 6 feet itself, so you
would expect to have 12 feet at your disposal. In practice, it's more
like 9 or 10 feet you can safely use before running into problems.
Try to reduce your cable length in whatever way possible. We were
successful in getting one expansion box that holds 6 5-1/4" disks
and an Exabyte drive connected to an Indigo to work where 3 expansion
boxes for the disks and the box for the Exabyte drive, when connected,
would cause SCSI timeouts like you mentioned.
Secondly, It would appear that there was a problem with *some* of the
D revision SCSI chips that Wangtek supplied to SGI. The problem would
appear (for us, at least) after you hooked up a second external device
to the machine. It was probably some sort of cable-length threshold
that caused the problems.
Before you start calling SGI for a replacement, Do yourself a favor
and make sure your cabling is ok, and make sure you use SGI's
terminators.
Personally, I now use Differential SCSI wherever possible.
--- 2 ---
| There are several things that could be at fault. I am presuming that
| you are using Single Ended SCSI.
Yes, they are.
| First and foremost is that your SCSI cable lengthis too long. This is
| common enough that you should really examine the length. Besides the
| external cables you're using between your devices, remember the
| lengths of the cable inside your peripheral boxes. The Max length on
| a SCSI bus is supposed to be about 18 feet, but the machine takes up
| some of that length electronically. I was told (by the SGI support
| line) that the Challenge M, for example uses up 6 feet itself, so you
| would expect to have 12 feet at your disposal. In practice, it's more
| like 9 or 10 feet you can safely use before running into problems.
Nope. Either they misunderstood you as to which machine, or gave you
just plain bad info. Challenge M is an Indigo2, and has about 15-20
cm's of internal 'cabling' (really, just PC board traces). The rest
of what you say is correct though.
| Secondly, It would appear that there was a problem with *some* of the
| D revision SCSI chips that Wangtek supplied to SGI. The problem would
| appear (for us, at least) after you hooked up a second external device
| to the machine. It was probably some sort of cable-length threshold
| that caused the problems.
Not WangTek, Western Digital. The problem is that the chip will see
(some of the chips, not all of them) transitions at 2 volts on the scsi
bus, rather than 2.85. Rev D chips were not used in Indigo, just
Indigo2, and some prototype Indy's. Production Indy's are using rev C
chips, since they were affected by this due to different system
design. Rev E 33C93B's have this problem fixed, and they will be cutin
as they become available (on Indy). Rev D had some improvements for
better noise immunity to rev C, but those have not been seen to be
terribly noticeable. The chip is a surface mount part, so changing it
would be a board swap. there are *NO* plans to do any board swaps, as
no systems (other than Indy) with rev D parts have been shown to have
problems with properly cabled and terminated.
| Personally, I now use Differential SCSI wherever possible.
The problem is that there are a very large number of SCSI devices
not available in differential scsi, and single ended to differential
SCSI adapters can introduce problems of their own. Certainly
differential scsi has significant advantages for cable length
and noise immunity, particularly at fast SCSI rates.
(11) - Making a new Boot disk
---------------------------------------------------------------------------
I would like to copy the contents of a boot disk (with / and /usr
partitions) to another, larger disk. I used fx to format the second
disk as a "boot" disk, mounted the / and /usr on the second disk,
copied all the files from the original disk, tried to boot with the
new one, and the system complains that it can't find the bootfile (I
didn't expect it to be that easy, but it was worth a shot). So, is
their an easy way to do this or do I have to do it the painful way?
cd /stand; dvhtool -v c sash sash -v l /dev/rdsk/dks#d#vh
Some systems also have ide and/or symmon in the volhdr, depending
on system type.
dvhtool -v l
lists the contents in the volhdr on the root drive; specify the
drive to list other drives.
(12) - Accessing VAX Tape Drives from Indigo
---------------------------------------------------------------------------
I have been attempting to determine what can be done about the
following problem (I have been speaking with a tech support person at
TGV, Inc., the manufacturer of Multinet, which is the best TCP/IP and NFS
software available for VAX/VMS):
>> >> You'll have to talk to SGI. Last I heard from them was about a month
>> >>before 4.0.5 was released. Their tape driver/rmt server would not
>> >>return any indication an EOF was incountered with fsr or fsf.
>> >>I was told this would be fixed, but not for 4.0.5.
>> >>
>> >> As I mentioned I know bsr,fsr doesn't return any indication
>> >>when an EOF in encountered. This makes doing VMS tape operations
>> >>impossible.
Note that this problem only exists with IRIX 4.0.5 and earlier. No other
implementation of Un*x exhibits this behavior.
Does anyone have any idea when this problem will be fixed? Or, if this is a
zero priority item for SGI, is there a possible fix of some sort available?
The particular configuration consists of a VAX running VMS V6.0, Multinet
V3.2A (I have been told to upgrade to V3.2B, which might help a little
bit), and Iris Indigo running IRIX 4.0.5 (I have also been told to upgrade
to 4.0.5f -- will this help?).
Thanks for any suggestions -- it would be good not to have to be completely
redundant and purchase additional tape drives just for the Indigo.
BTW, what I am attempting to do is access the tape drives on the VAX
from the Indigo.
----- 1 ------
Then the problem listed above is completely irrelevant, since you aren't
using the Indigo tape driver at all, and presumably that means you
didn't quite explain the situation right to the folks at Multinet.
The problem he refers to was fixed sometime before the 4.0.5 Indigo
Patch was released. At least, his test case passed. Again, that was
with the tape drive *on the SGI system*.
(13) - Indigo CPU/SCSI Board Problems
---------------------------------------------------------------------------
Twice now in the space of 2 days our Indigo has died.
The first time the SGI technician replaced the cpu board, but
didn't find any obvious cause, and now it's happened again.
Symptoms are messages on pressing the reset button:
sc0,1,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus
sc0,2,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus
etc
and now
sc0,1,0:cmd=0x28 timeout after 10sec. Resetting SCSI bus
sc0,2,0:cmd=0x12 timeout after 5sec. Resetting SCSI bus
etc
with the external and 2nd internal drive removed, and external
termination replaced.
System is R4K-XS24Z, 10 months old, 48M ram, internal SGI
500M hard disk, internal Parity Micropolis 2112 1G hard disk,
external HP magneto-optic disk with Ten-X Optical Conversion
Unit. The magneto-optical unit has been working for 9 months.
The Micropolis 2112 has been working 2 weeks, during which
time we changed buildings, so the system has been switched
off quite a bit. (Yes, we did check the cables, reseat the boards
etc. when we saw that it was a SCSI problem.)
In both cases, the problem occured when re-configuring the
Xinet Appletalk server, which involved in one case re-configuring
the kernel, which then apparently crashed and corrupted the
"free block count" on the root partition.
It is difficult to understand how a hardware problem could have
been produced by these software problems, but the Indigo made
a soft 'brrp' sound when it crashed the first time, but then got
to the final stage of rebooting, after auto fsck'ing the disks reporting:
"NAME=/tmp/atinitA1601 [EMPTY] removed" and then in the final
stages, just before the login screen should appear.
"IRIX killed due to bus error"
Resetting once more, it again reached the final stage of rebooting
before the cpu made a soft click (shudder), and then died i.e. refused
to read the SCSI bus, giving the timeout errors.
The SGI guy will not be happy having to drive 60 miles to replace
the cpu board again, and still not knowing what could be the cause.
He could only say that a recent SGI technical note advised using
active terminators in the case of SCSI problems. (We already
looked at the cable - it is short and of good quality). But could
a 'simple' termination problem blow something on the cpu board ?
--- 1 ---
| Twice now in the space of 2 days our Indigo has died.
| The first time the SGI technician replaced the cpu board, but
| didn't find any obvious cause, and now it's happened again.
|
| Symptoms are messages on pressing the reset button:
| sc0,1,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus
| sc0,2,0:cmd=0x25 timeout after 2sec. Resetting SCSI bus
| etc
| and now
| sc0,1,0:cmd=0x28 timeout after 10sec. Resetting SCSI bus
| sc0,2,0:cmd=0x12 timeout after 5sec. Resetting SCSI bus
| etc
| with the external and 2nd internal drive removed, and external
| termination replaced.
|
| System is R4K-XS24Z, 10 months old, 48M ram, internal SGI
| 500M hard disk, internal Parity Micropolis 2112 1G hard disk,
| external HP magneto-optic disk with Ten-X Optical Conversion
| Unit. The magneto-optical unit has been working for 9 months.
| The Micropolis 2112 has been working 2 weeks, during which
| time we changed buildings, so the system has been switched
| off quite a bit. (Yes, we did check the cables, reseat the boards
| etc. when we saw that it was a SCSI problem.)
Take out the micropolis; and see if that fixes things. Same for
the external device. Double check that you don't have extra
termination. Make sure the external scsi cable is high quality.
Use active termination. Make sure no pins got bent anywhere, or
cables badly kinked during the move. I strongly doubt it is
the cpu board or the backplane.
| "IRIX killed due to bus error"
Could be SCSI related. Could also be many other things, including
s/w problems. If it happened just after installing s/w that has
kernel parts, I would very strongly suspect that s/w, and delete it
and go back to the old kernel, to find out (you did save a copy of
the old kernel, right ;) ?)
| Resetting once more, it again reached the final stage of rebooting
| before the cpu made a soft click (shudder), and then died i.e. refused
| to read the SCSI bus, giving the timeout errors.
|
| The SGI guy will not be happy having to drive 60 miles to replace
| the cpu board again, and still not knowing what could be the cause.
| He could only say that a recent SGI technical note advised using
| active terminators in the case of SCSI problems. (We already
| looked at the cable - it is short and of good quality). But could
| a 'simple' termination problem blow something on the cpu board ?
Again, I strongly doubt you have a cpu board problem.
--- 2 ---
>Again, I strongly doubt you have a cpu board problem.
Yes, I find it hard to believe too. But we did take out the extra
disks and put back the original SGI terminator, power cycled etc.,
but still had the SCSI timeout - even with all disks removed.
We did keep a copy of the old kernel, but since the beast can't
find the SCSI drives, its not much use. Yet replacing the cpu
board immediately cured it - for two days, after which we had the
exact same problem.
Our own technician opened up the magneto-optic drive, and grumbled
that it had internal termination, but it has been working happily
for 9 months, with or without external termination (it is the only
external device). OK, maybe the (new) second internal drive finally
broke the SCSI camel's back, but ...
Again, can a 'simple' termination problem blow something on the
cpu board ? The SGI guy will be back this pm, but he seems as
puzzled as I am. I fear he is going to tell us it 'must be' the
third party drives, and that we can't use them.
--- 3 ---
>|But could a 'simple' termination problem blow something on the
>|cpu board ?
Well the sequel is that something to do with SCSI was blown on both
cpu boards. On replacing the second, the SGI engineer asked me not
to connect the external magneto-optic drive, and I've had no more
problems for a week.
But this external mo-drive has been working perfectly for 9 months,
the SGI guy could not suggest what might be wrong with it, how we
could test it, or even what precisely was blown on the cpu boards,
and what might cause it - apparently they are shipped back to SGI and
the local engineer never gets to hear what the problem with them was.
We really need that mo-drive. The only things we did before the
problems were to move buildings and add a second internal drive,
(Micropolis 2112) which seems to work fine.
--- 4 ---
| Well the sequel is that something to do with SCSI was blown on both
| cpu boards. On replacing the second, the SGI engineer asked me not
| to connect the external magneto-optic drive, and I've had no more
| problems for a week.
There simply isn't anything that I know of that can blow. The termpower
is protected by a PTF device, rather than a fuse, and that is on the
backplane rather than the CPU board.
There are also some EMI filter caps, and those might *conceivably*
short out and cause problems, but they are also on the backplane,
not on the CPU board.
It is just barely possible that the SCSI controller itself is
being destroyed, but that would be *very* difficult to do. Even
plugging in the SCSI bus reversed won't do that.
It is, of course, difficult to argue with the fact that 2 cpu
boards have failed. Coincidences happen, but this is a bit much...
| But this external mo-drive has been working perfectly for 9 months,
| the SGI guy could not suggest what might be wrong with it, how we
| could test it, or even what precisely was blown on the cpu boards,
| and what might cause it - apparently they are shipped back to SGI and
| the local engineer never gets to hear what the problem with them was.
This is not really correct. See if you can get ahold of him ASAP, and
have that board specially tagged for analysis in our logistics depot,
and if they can't find the problem, by engineering. When that is done,
the field folks get the results. In the normal case, they don't.
| We really need that mo-drive. The only things we did before the
| problems were to move buildings and add a second internal drive,
| (Micropolis 2112) which seems to work fine.
About the only other thing I can think of, until the board problem
is determined, is to talk to the M-O drive vendor for any known
problems with the SCSI interface (spikes, strange voltages, etc.)
--- 5 ---
>There simply isn't anything that I know of that can blow. The
>termpower is protected by a PTF device, rather than a fuse, and
>that is on the backplane rather than the CPU board.
I did not see the start of this, but I can make one suggestion based on
experience.
Be very sure that all devices are plugged into the same circuit, and
the same outlet on the same circuit. I have seen ground loops cause
various bits of equipment to melt, explode, and stop working. I saw
a printer combust this way, and personally killed serial port drivers
on a 4D25.
A transient ground loop of 10 volts might be possible on a 220VAC
system, like yours in France. Typically the SGI and external SCSI
device are only connected by the SCSI cable. This type of thing is
not typically tested by system builders. If you are using part of
a three phase setup, and have high powered switching equipement on
another leg sharing common neutral, I'd bet lunch the voltage of
common is being dragged around a bit too much.
Less likely, but a real problem in this building is power distribution.
The main power panel is through a wall at the end of a lab. The steel
frame and conduit in that corner set up and antenna that makes all
moniotor unreadable, and cause mysterious crashes.
The control room of MIT's ALCATOR C-MOD fusion reactor finally went
to a double optical isolation after a few-volt, few-million-amp
ground fault caused a room full of Suns ( and other expensive
equipment ) to turn to plasma. Reality is a wonderful teacher.
Grounding problems can be hard to detect, and hard to fix.
--- 6 ---
There seems to be some difference of opinion about how easy it is to
blow something on the Indigo cpu board by possibly malfunctioning SCSI
devices, or by simply disconnecting a SCSI device without powering
everything down.
>| Well the sequel is that something to do with SCSI was blown on both
>| cpu boards. On replacing the second, the SGI engineer asked me not
>| to connect the external magneto-optic drive, and I've had no more
>| problems for a week.
>
>There simply isn't anything that I know of that can blow. The
>termpower is protected by a PTF device, rather than a fuse, and
>that is on the backplane rather than the CPU board.
>
>There are also some EMI filter caps, and those might *conceivably*
>short out and cause problems, but they are also on the backplane,
>not on the CPU board.
>
>It is just barely possible that the SCSI controller itself is
>being destroyed, but that would be *very* difficult to do. Even
>plugging in the SCSI bus reversed won't do that.
Yet, the local SGI engineer says that his colleagues (in Paris) have
had to replace cpu boards after SCSI problems, and another user
(perhaps he would prefer to remain anonymous) emailed me:
>I blew up the SCSI drivers on my CPU board by disconnecting an
>external SCSI device without powering down the system.
>I'm 100% certain, because I did it twice. The first time, when
>I forgot to turn off the Indigo, it fried the CPU drivers, the
>second time an internal hard disk when I didn't turn off the
>external CD-ROM.
On the other hand, I have seen a (software) engineer unplug a
CD-ROM drive from a running Indigo, and to my shocked question,
replied that it was OK if the machine was not accessing SCSI.
Mind you, the engineer in question was president of DECUS. Maybe
he just didn't like Indigos ;-)
--- 7 ---
| There seems to be some difference of opinion about how easy it is to
| blow something on the Indigo cpu board by possibly malfunctioning SCSI
| devices, or by simply disconnecting a SCSI device without powering
| everything down.
Please, please, please! Since you have had support folks in Europe
tell you that they have seen this problem, *have them get in touch
with us in Mt. View*!!! I know it seems crazy to be asking a customer
to have SGI field folks get in touch with headquarters, but
unfortunately, I have no idea who these folks are.
No similar reports (other than Alan's) have reached me internally, and
if we have a problem, we need to know about it. I've very badly
abused the SCSI bus, not once, but literally thousands of times, on
dozens of systems, with hundreds of different peripherals, and never
seen anything like this. So either something has changed, or we
have a powersupply issue that shows up more on European power, or
there are some common peripherals in Europe that we haven't seen,
that trigger problems we haven't seen.
| Yet, the local SGI engineer says that his colleagues (in Paris)
| have had to replace cpu boards after SCSI problems, and another
| user (perhaps he would prefer to remain anonymous) emailed me:
|
| >I blew up the SCSI drivers on my CPU board by disconnecting an
| >external SCSI device without powering down the system.
| >I'm 100% certain, because I did it twice. The first time, when
| >I forgot to turn off the Indigo, it fried the CPU drivers, the
| >second time an internal hard disk when I didn't turn off the
| >external CD-ROM.
There *are* no SCSI driver chips in Indigo. There is one, single, SCSI
chip, with integral drivers. The only way I've ever been able to blow
them is to solder them in wrong (and it is pretty spectacular; a good
way to get a look at the die itself!). The only other components
on the Indigo SCSI bus are passive (termination resistors, and filter
caps). This is what has me confused and concerned.
Again, to repeat what I said above, I have never seen reports of this,
and not a whisper of any cases where something else on the SCSI bus was
damaged!
| On the other hand, I have seen a (software) engineer unplug a
| CD-ROM drive from a running Indigo, and to my shocked question,
| replied that it was OK if the machine was not accessing SCSI.
| Mind you, the engineer in question was president of DECUS. Maybe
| he just didn't like Indigos ;-)
I've done it many times also. With the PTF (as opposed to a fuse),
it is pretty safe. Mind you, it is *not* officially supported!
(14) - Exabyte 8205 on an Indigo2
---------------------------------------------------------------------------
The subject pretty much says it all; I'm trying to get an Exabyte 8205
working on an Indigo2, IRIX 4.0.5H and am looking for a tpsc table
entry for this drive, preferably one that supports both the EXB-8200
and EXB-8200c (compressed) modes. Thanks.
A few days ago, I asked if anyone had a master.d/tpsc entry for
an Exabyte 8205. Although I only got one response (w/ an entry
for an 8505, not an 8205), using it together with the info the
vendor gave me, the drive manual, and the similar info posted to
this newsgroup previously, I was able to put together a working entry.
The drive is now working happily in both standard and compressed modes.
Below is the entry I used, as well as the mods. to /dev/MAKEDEV to
create the device special files. To the best of my knowledge, the
entry (and comments I make) below are correct, but of course, I
can't guarantee this. Also, I haven't tested all the MTCAN_*
options (eg, SEEK, SILI), but the drive manual says they're
supported, so they *should* work (I don't know how the irix scsi
tape driver implements these functions).
--------------------
In /usr/sysgen/master.d/tpsc:
/* Exabyte 8205: this drive supports two formats: EXB-8200 and
* EXB-8200c (compressed). The SCSI command set used by this drive
* is similar (if not identical) to the Exabyte 8500, so this
* definition is based on that drive; the only difference is the
* product ID string (tp_product[]) and the density values
* (tp_density[]). Usage of the density modes is significant only
* when writing, as the 8205 automatically selects the correct
* density when reading.
*
* The meaning of the density values are as follows:
*
* Value Format Written Notes
* ----- -------------- -----
* 0x00 EXB-8200c format This value is ignored by the drive if
* used when writing to an EXB-8200 tape
* when not at BOT (ie, EXB-8200 format
* will be written instead).
* 0x14 EXB-8200 format Using this value will return an error
* (drive returns Check Condition status)
* if used when writing to an EXB-8200c
* tape when not at BOT
* 0x7f No change The format written will be the same
* as what is on the tape. If tape is
* blank, then the drive power-on default
* format will be used (set in EEPROM, usu.
* 8200c format)
* 0x90 EXB-8200c format Using this value will return an error
* (drive returns Check Condition status)
* if used when writing to an EXB-8200
* tape when not at BOT
*/
{ EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8205", 6, "\40\4\16\0\200\7",
{0x7f, 0x14, 0x90, 0x0},
MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC|
MTCAN_SEEK,
80, 4*60, 25*60, 5*60, 1024, 128*1024},
The mods to /dev/MAKEDEV are:
*Device:*EXB-8205*) \
set v nrv nsv nrnsv ; \
for add in 4 5 6 7 ; do \
mdev=`expr $$minor + $$add`; \
mknod $${prf}$$1 c $$maj $$mdev; \
shift; \
done; \
for dens in 8 24 ; do \
case $$dens { \
8) kden=8200;; \
24) kden=8200c;; \
}; \
set "" nr ns nrns v nrv nsv nrnsv ;\
for add in 0 1 2 3 4 5 6 7 ; do \
mdev=`expr $$minor + $$add + $$dens`;\
mknod $${prf}$$1.$$kden c $$maj $$mdev;\
shift;\
done; \
done ;; \
This will create a total of 24 special files; 8 (nr, ns, nrns, etc)
for each of the first three density values given in the tpsc entry
(0x7f, 0x14 and 0x90 in the example above--I chose not to create
special files for the 0x00 density value as this essentially has
the same functionality as the 0x7f value).
If anyone has any corrections to the information above, I'd be glad to
hear them.
(15) - Disks for Indy's
---------------------------------------------------------------------------
We just ordered some INDY's. We had to order them diskless, because
SGI's disk prices were too high (yes, we grumbled at our sales person
about it). Of course, the next step is to order some 3rd party disks.
One of the local SGI engineers told me the disks that SGI is
shipping in the INDY are the Seagate ST3600 and ST31200.
Is this correct?
I called our usual supplier, and got the following prices:
ST3600N - 525Meg 3.5" low profile disk $859
ST31200N - 1052Meg 3.5" low profile disk $1544
ST11200N - 1.2Gig disk, in tabletop enclosure $1389
The prices for the first 2 includes a 1 year on-site maintenance contract.
The third disk price includes 3 years on-site maintenance, and a 5 year
warranty. All the disks are fast SCSI-2.
Any reason not to buy the ST11200N? It is cheaper and slightly
larger (in Meg) than the ST31200. Also, since it is in an
external enclosure, the INDY power supply won't have to work
as hard, and it will be easier to move disks around (some
people were saying it is difficult to get at the INDY internal
disks).
One more gotcha, the quote said "ST31200 available late November".
As long as you don't mind the extra enclosure, it should work fine
(no promises though). The 11200N is what we are selling on the
Indigo2.
Make sure you get new enough firmware that it doesn't have the
"goes away and won't respond to selection" bug.
The difference in the load on the power supply in the Indy will be
negligable.
(16) - Indy Graphics
---------------------------------------------------------------------------
|> We have an Indigo with XS24 graphics. We've written an application that
|> uses a double-buffered 12-bit plane for images and a 4-bit
|> overlay plane for xwindow controls. I am thinking of buying an Indy SC
|> soon with 24 bit graphics to host this app. Can this machine
|> handle the same visuals as the Indigo?
|>
|>
Not quite. The 24-bit Indy graphics does support 12-bit
double-buffered (both pseudoColor and TrueColor) but it has
two overlay visuals of depth 8 and 2, rather than the three
overlay visuals of depth 2,2 and 4 of the XS24
Note that the 4-bit overlay visual on XS24 shares bit planes
with the two 2-bit visuals. The Indy 8 and 2-bit overlay visuals
are completely independent (i.e., separate bit planes).
(17) - VME Interrupts
---------------------------------------------------------------------------
How are the VME interrupts (Levels 0-7) mapped to the
CPU interrupts? I have a VME board that is triggering
VME Level 5, 6 & 7 interrupts. I can see the interrupt
lines asserted on a logic analyzer. However, for some
unknown reason only Level 5 gets to the kernel. Levels
6 & 7 don't do anything. I know that the kernel routines
spl0, splnet, splvme, ... can be used to block interrupts
at the CPU, is there a similar routine to mask VME interrupts
at the VMEinterrupt handler? How about hardware jumpers?
Could I have something jumpered incorrectly that would
mask certain VME level interrupts? I'm almost positive
that /usr/sysgen/system is setup correctly for the
other levels. Any Ideas?
--- 1 ---
First, you should get the Device Driver Writer's Guide, which
talks about a lot of these issues. The answers vary from system to
system.
For the low end systems, there is only one VME interrupt to the
cpu, and the vector is then used to determine which device interrupted.
I don't remember how this works on the high end, but I think it is
similar.
--- 2 ---
I have just one quick addition to what Dave said here. We do mask
individual VMEbus levels before they get to the CPU. This is vital to
allow for us to respond to only certain VME interrupts, while allowing
another interrupt handler to take ones not intended for us. At kernel
generation time (lboot, autoconfig), the system determines which
VME device drivers are going to be built into the kernel, and puts them
on a list. Then, at system start up time, for each device, the
corresponding VMEbus interrupt level is unmasked. So, if you are seeing
the interrupt get through on some levels, but not on others, you
probably just have your kernel configured with device drivers for those
levels that do get the interrupt. To see which devices are being
configured in, you can run lboot with the -v option which will print the
results of the probes for devices. Then, you can compare that with the
levels for those devices as specified in the sysgen/system file.
(18) - Extending Keyboard, Mouse and Video signals
---------------------------------------------------------------------------
We're finishing ordering our new ONYX with a RE^2 and
two Raster-Engines. We need to drive the video about 150
feet, in an optimal setup(tm) . It's not my idea(tm) but
a guy who wants to run Alias that far from his ONYX/RE^2.
SGI kindly sells for a very attractive(!!) price a 75' kbd/mon/rat
extension. Can you hook two(2) together, or do you have to
go to some(please fill ________________) vendor(_______phone #)
to get a longer one with an amplifier??
--- 1 ---
Technically, yes, but your image on the monitor would be
unacceptably dim. You need some sort of amplifier.
--- 2 ---
There are two companies that I know of that can connect the
keyboard, mouse and monitor to an SGI system separated by
150' or more. I have the address and phone for one, but not
the other. The one I don't have the address for is called
Lightwave Communications. I've seen ads for them in some
of the Unix magazines.
The one I do have info for is:
Meret Optical Communications, Inc.
1800 Stewart Street
Santa Monica, CA 90404
PH: (310) 315-1422
Both of these companies send the keyboard mouse and video
information over fiber optic links with a box at each end.
It's more expensive than a straight cable, but can be
extended to much more than 150'.
--- 3 ---
>the other. The one I don't have the address for is called
>Lightwave Communications. I've seen ads for them in some
>of the Unix magazines.
LightWave Communications
84 Research Drive
Milford, CT 06460
(203) 878-9838
(19) - More SCSI for Challenge M
---------------------------------------------------------------------------
Is there any chance that SGI will have additional SCSI bus cards for the
Challenge M? We are currently using our machines for "small" projects, and
there is the chance that they may need more disks on the machines.
Does or will SGI sell a card that will do this?
--- 1 ---
Such a card is being worked on. I don't know if it will be
a product or not. Talk to your sales folks. If done it would
likely be a wide/fast SCSI channel, possibly differential.
It would be nice to get more than one channel, but i/o panel
space is the limiting factor.
--- 2 ---
You might also consider the new 2.0GB internal disk for the Challenge M.
(20) - Device Driver Guide for 4.x versus 5.x
---------------------------------------------------------------------------
>You can order M4-DVDR-2.0 for IRIX 4 and M4-DVDR-3.0 for IRIX 5.
How different are the two manuals? If I get M4-DVDR-3.0 will it
cover IRIX 4 info as well? I'd only like to get one manual and
we're currently working with IRIX 4.0.5, will I be able to tell
the differences between 4 and 5 in M4-DVDR-3.0?
The one for IRIX 5 has *some* info that talks about the differences,
and there is a lot of stuff that didn't change, but in general, you
*really* want the one for the O/S you are working with.
There were a *lot* of changes in kernel internals from 4.x to 5.x
(relatively few between 3.x and 4.x).
(21) - Trouble with Indigo Disk Drive
---------------------------------------------------------------------------
I need some help with my system disk /usr partition.
When I boot the system (INDIGO R4000) I get a error message from fsck
that BLOCK 1 is bad!. I've tried using fsck -g /usr/dsk/dks... and I get
the message:
Primary superblock inaccessabe or invalid. Trying secondary.
No filesystem on /dev/dsk/dks0d1s1.
Message repeated about 30 times.
Can this be fixed??!!
Sounds like the drive isn't responding at all. Are you sure
the drive ID wasn't changed, and that the drive was recognized?
(Check the hinv output). Looks like it is seen OK, from the
message you show above.
Can you bring up fx on the drive?
Why are you trying partition 1 on drive 1? That is normally
the swap area, and the only time it will normally have a filesystem
is when the miniroot has been loaded and booted (it gets copied
to the swap area).
(22) - Bru for floptical?
---------------------------------------------------------------------------
Can anyone tell me if bru will work with floptical drives ?
Probably (I've never tried it), but I doubt that multivolume
will work unless you specify the right -s option value.
(23) - Using serial port to detect a switch closure
---------------------------------------------------------------------------
I need to write a program to act as an external switch on an Indigo.
I've tried using cxPortAccess routines but I guess my makefile isn't
working correctly and even if it was I'm still just guessing. Can
anyone help me with a few lines of code which would detect a switch
closing across a few pins on a modem cable plugged into the serial port
and then trigger a frame grab. Even a partial solution would be greatly
appreciated. You can post here or mail me either as winsorr@cuug.ab.ca
or better still 73223.2374@compuserve.com. (I get my compuserve mail
more regularly than my real Internet mail...sigh.)
Thanks, I have a solution. The switch can be done by a tiny program.
I fopen /dev/ttym1. The program hangs until I short pins 4 and 8.
The video capture I got from usr/people/4dgifts/sv/examples/video/indigo
Filename oneframe.c
(24) - Toshiba XM3401BC on Indigo
---------------------------------------------------------------------------
I just bought a CDROM Toshiba XM3401BC from a third party
which I cannot connect to my Indigo XS. No matter which
SCSI address I use, the hinv command doesn't show me any
CDROM.
Maybe I was misinformed and this CDROM cannot be used on
Indigos or I need a patch for this CDROM. I hope somebody
can give me a hint or some other information about this
CDROM.
--- 1 ---
Are there errors on the console during boot? If correctly
connected, almost any CD-ROM drive should at least show up
in the hinv output, even if it doesn't work correctly.
Some might show up as a disk, in some weird cases, but they
should show up. Are you sure it is connected, terminated,
and powered on?
--- 2 ---
During booting I got a message for nearly one millisecond which I
found in /usr/adm/SYSLOG :
Oct 7 13:39:56 dix syslogd: restart
Oct 7 13:39:56 dix unix: IRIX Release 4.0.5F IP20 Version 08280217
System V
Oct 7 13:39:56 dix unix: Copyright 1987-1992 Silicon Graphics, Inc.
Oct 7 13:39:56 dix unix: All Rights Reserved.
Oct 7 13:39:56 dix unix:
Oct 7 13:40:00 dix inetd[120]: /usr/etc/rpc.snoopd: No such file
or directory
Oct 7 13:40:00 dix inetd[120]: /usr/etc/cvpcsd: No such file
or directory
Oct 7 13:40:00 dix inetd[120]: /usr/etc/podd: No such file or directory
Oct 7 13:40:00 dix timed[131]: slave to cicely
Oct 7 13:40:02 dix sendmail: starting
Oct 7 13:40:06 dix syslogd: restart
Oct 7 13:40:08 dix lpsched[178]: can't open output queue file
Oct 7 13:40:08 dix FaxServer[205]: OPEN "/dev/ttyd2"
Oct 7 13:40:11 dix cdromd[211]: /dev/scsi/sc0d4l0 is not a valid
CD-ROM drive
Oct 7 13:40:11 dix /usr/etc/cdromd[210]: Unable to start mount
daemon for /dev/scsi/sc0d4l0 on /CDROM
Oct 7 13:40:41 dix Xsession: root: login
Oct 7 13:40:44 dix Xsession: root: all hosts being allowed (access
control disabled)
The file /etc/fsd.auto looks like follows:
/dev/scsi/sc0d4l0 /CDROM cdrom ro 0 0
The CDROM is connected, terminated and powered on, so this cannot
be the problem. Even the SCSI address is set to four.
I hope this information is of any help.
--- 3 ---
Does it show up in the PROM hinv? Does anything else in hinv
look strange (like more disks showing up than you know you have,
or anything else at SCSI ID 4)?
Can fx open the CD (fx -x 'dksc(0,4)') ? Is there media in the
drive (ISO9660, or EFS)?
If fx can open the drive, what does it show for the inquiry
info (should be similar to this; which is for the older SGI
version of the Toshiba 3301):
...controller test...OK
Can't get drive geometry, assuming 64 sectors/track
Can't get drive geometry, assuming 8 heads
Unable to get device geometry, assuming default
Scsi drive type == TOSHIBA CD-ROM XM-3301TA1971
--- 4 ---
Maybe he isn't turning the CD-ROM on BEFORE turning on the Indigo.
One needs to turn on ALL SCSI peripherals FIRST and the Indigo last.
If you don't, the system will NOT know the device is there.
--- 5 ---
To whom it may interest:
I found the problem I had with my CDROM Toshiba XM3401BC. It was just
as simple as two cables which were badly connected in the CDROM case.
So it didn't matter which SCSI address I used, in the device it was
either zero or one.
One thinks that these components are checked before leaving the factory.
At this point I want to thank all the people who answered my inquiry
and tried to help me.
(25) - Software protection
---------------------------------------------------------------------------
Does somebody know a software protection method which guarantees that the
software can only be used up to a specific date? Or, is there any hardware time
available which is absolute and cannot be set or manipulated, and how can this
time be got?
--- 1 ---
No, there is no time on any SGI system that can't be changed by the
user.
--- 2 ---
Usually people compensate by making a program which scan the
disk for file access times, If it finds any file access time which
are ahead of the current date, then it blows up the program.
Also you can create a file on installation of the program, touch
it with an start date, then imbed that date into the file. (encoded
with your own encryption key) When starting up the program, check
the creation date of the license file to make sure that it is the
same as the imbedded date, and the system date is prior to or after
that date. (depending on whether you want a 30 day type license or
a termination date license.)
I've found several (which won't be mentioned) vendors which do not
monitor the system clock at all making it easy to extend licenses.
(26) - Using 'setmon'
---------------------------------------------------------------------------
In Pipeline's september/octopber 93 edition, page 19, there is a table
that says that Indigo XZ24 systems can produce component RGB signals
by using a setmon command. Do you confirm this ? I tried to use
setmon but the system doesn't recognize the command.
Try /usr/gfx/setmon. The /usr/gfx directory is not normally
in a user's path variable.
(27) - Fastest Baud rate for serial ports
---------------------------------------------------------------------------
What is the fastest baud allowed for serial port on an Indigo R3K or R4K ?
57.6K, 38K or only 19.2 ?
38400bps is the fastest async rate on the serial ports.
(28) - Odd baud rates
---------------------------------------------------------------------------
I have someone here at work that needs to access the serial port
at a baud rate different than the presets.
It's like 32000 baud.
Is there a program that can set the serial port to odd rates ?
Not really. When put into 'EIA 422' mode, as is done with midi, it
can sync up to an external clock. That *might* do it, I don't know.
(29) - SCSI Devices on Twin Tower machines
---------------------------------------------------------------------------
We are investigating the addition of a DEC CDROM to our SGI 4D/220GTX.
THis is a dual tower machine with an integral tape drive in the
power supply tower, and a hard disk stacked on top. Inside the disk
module are standard scsi 50 pin IDS connectors, two on an interface
board that interconnects from the device stacked below. I would
imagine we could disconnect one of the IDS connectors and attach
a flat ribbon cable with an adapter for the centronics type external
cable, like the DEC and most other external scsi devices. WHich
one of the connectors should we disconnect? SHould we install
an terminator on the CDROM?
The CDROM isn't intended to become a permanent fixture in the SGI,
so we might like to install an external type scsi connector somewhere.
My instincts lead me to beleive the cleanest way to do this would
be buy one of the stackable modules for expansion, and install a
connector on the back. I believe these are available, anyone
have the source?
--- 1 ---
>how do we install a terminator on the CDROM?
There are two ways the right way and the cheap way.
The right way:
Order a P5-Xscsi - twin tower drive expansion tray, This tray includes
and external scsi on the back, with a centronix style terminator
The cheap way:
If you already have an IO3 board (type hinv) then the second scsi
bus can be brought to the backplane in a centronix type connector.
(I'm not certain if this modification was ever approved (FCC))
There was talk about doing that.
If you don't have an IO3 (Older gtx's have IO2) an IO3 upgrade
may be costly but will bring you performance and flexability. Talk
to your local SE or SSE they should be able to give your prices
and performance numbers.
(30) - Connecting Video Projectors to SGI platforms
---------------------------------------------------------------------------
We're trying, without success, to connect a Crimson to a SONY video
projector, one of those gizzmos you see in lecture rooms that takes a
computer's display output and projects it to a large screen.
The projector has a red, green, blue, and sync inputs. The Crimson has
a red, green, blue, and sync outputs. We connect everything and get nothing!
How does one do what we want to do? Is it possible? Is special aux.
equipment needed?
--- 1 ---
This is commonly done. The most likely problem you have is that the
projector isn't compatible with the high-resolution video coming
from your Crimson.
You may (depending on the type of graphics board in your Crimson)
be able to change your video output to something that the monitor
can display. See the setmon(1G) man page.
You might also turn off sync on the R, G, and B guns (setmon -sn)
since most projectors object to it.
--- 2 ---
When we hooked up a Barco projector to the crimson, the Barco was
not able to scan fast enough for the output rate of the VGX.
The barco was later upgrade to support upto 80 Hz. Also by default
the sync signal is on the green output from the crimson.
(31) - Using 'sysid' for software licensing
---------------------------------------------------------------------------
We distribute software for SGI machines. The software is licensed so
that it only runs on one machine.
This is implemented by reading the sysid in the program.
Now the other day a strange thing happened - a customer requested a license
for one machine ID, and we sent it to him, no problem.
BUT:
A day after we got a fax saying, "because we run some other software on
this machine, this software makes other programs think that the sysid is
different", i.e. without this (unnamed) software, the sysid would be
69xxxxxx, and when it is running, the sysid returns 12xxxxxx to other
programs.
Can this really be true?
The code (our program) is not linked against shared C library (-lc_s)
===
so this can't be the problem.
If this is true (and I have no reason to believe otherwise), is there a
way of getting the "true" sysid always?
| This is implemented by reading the sysid in the program.
How? Are you actually using sysid(), or are you doing something
else?
The only way sysid() can change is with hardware changes, or on
Onyx/Challenge, when 5.1 is installed (to fix a bug in sysid that
caused duplicate id's in 5.0.1).
If you are using something other than sysid(), you need to tell
us what you are using. I have some strong suspicions on what you
are doing based on the numbers you included, but I'd like to have
you confirm them.
(32) - Books about MIPS processors
---------------------------------------------------------------------------
I'm searching for something about the R3000/R4000 RISC
processor (architecture, instruction set, etc.).
(To teach computer architecture at the ELTE Univ. Budapest.)
Book: MIPS R4000 Microprocessor User's Manual
by Joe Heinrich;
PTR Prentice Hall
Englewood CLiffs, New Jersey 01632
QA76.8.M523H45 1993
(33) - Wangtek DAT on an Indy?
---------------------------------------------------------------------------
Is it possible, to connect a Wangtek DAT-SCSI-Streamer Model: W6200HSX (2GB DAT)
to a SGI Indy?
Probably, but no guarantees. You'll need to edit
/var/sysgen/master.d/tpsc
(34) - DAT drive on Power Series Systems
---------------------------------------------------------------------------
According to SGI it is not posible to put a DAT (4mm) drive on this old
Power Series system. Is this really true, or is there a way to do
this? We have one of these with 2 1.2 gig disks, and no good way to
back it up except by get a couple dozzen DC6150 tapes and having
someone babysit the box, swapping tapes. Backing it up over the
network is not a posiblity (its only connection is a slow (19.2K BPS)
SLIP connection through an Onyx (which is very sensitive to massive
data streams (drops the connection)).
--- 1 ---
I believe that the DAT was never released on the older twin tower
systems (FCC, etc. testing was not done). But if you can somehow
connect a DAT to your system, and the DAT is like the one SGI sells,
it should work, as long as the SCSI connections, termination, etc.,
are right. [See (29) ]
--- 2 ---
We have an HP DAT drive on a 4D/240S which works just fine. If you
don't need the drive to support audio and can live with an external
drive, it will work for you as well. Supporting compression is a bit
more tricky and we didn't try it here so I cannot tell how is it like.
(35) - Serial Port & Modem Cabling for Indigo
---------------------------------------------------------------------------
I read the SGI faq - no help. I read the owners manual - It said a
twisted pair (for mac ) will work (3 wires), But no comment on hardware
handshake except 'You can buy it from SGI'.
--- 1 ---
I'm going to assume you're talking about an R3K Indigo.
From the "IRIX Advanced Site and Server Administration Guide", chapter
7 (available on-line through IRIS InSight):
------------------------------------------------------------------------
Mini-DIN8 Connector Cabling
There are 3 basic cable configurations for the Mini-DIN8 serial
ports. See your Owner's Guide to determine if you have a Mini-DIN8
port on your workstation or server. Depending on the cables used, some
functionality may be sacrificed. Note that the pinout of these
Mini-DIN8 connectors is different than that of the DIN connectors on
larger systems. These larger systems also have DB-9 connectors that
are connected to the same internal port hardware.
For most dumb terminals you should use a commercially available ``MAC
SE(R) to Imagewriter1(R)'' cable. This cable would use the normal 3
wire connection and be used as a /dev/ttyd* device. Table 7-5 shows
the pin configuration:
Table 7-5 Mini-DIN8 Serial Terminal Cable
Function Mini-DIN8-Male DB25-Male
1 nc
TXD 2 nc
GND 3 3
RXD 4 7
5 2
DCD* 6 nc
GND 7 20
8 7
* /dev/ttym* devices should be used with this cable only if
the system must notice when the terminal or printer is
powered off.
Note: A MAC SE cable also has some other pins connected but
they can be ignored.
For modem devices using RTS/CTS hardware flow control the following
pin-out will allow ``full flow control.''' This cable is required to
implement /dev/ttyf* devices. This cable will also support /dev/ttym*
devices. Table 7-6 shows the pinout:
Table 7-6 Mini-DIN8 RTS/CTS Modem Cable
Function Mini-DIN8-Male DB25-Male
DTR 1 20
CTS* 2 5
TXD 3 2
GND 4 7
RXD 5 3
RTS* 6 4
DCD 7 8
GND 8 7
* RTS and CTS are ignored (optional) if using /dev/ttym* but
required if using /dev/ttyf*.
Note: This cable is available from Silicon Graphics. Contact your
sales representative or SGI Express. This cable can be used
with a null modem adapter for terminals and printers (see
Table 7-2 above), though you should use this cable exclusively
for modem connections. The commercially available MAC SE to
modem cable (``off the shelf ''') will not work properly with
SGI software.
--- 2 ---
Generic Mac modem cables will not work (not enough pins) to support
high-speed (V.32 and faster) modems that require hardware flow control
and modem control lines. You can make your own cable -- the pinouts
are in `man serial`. SGI does sell the cables, and places like INMAC
will make them custom.
(36) - FDDI/CDDI on Indigo2
---------------------------------------------------------------------------
The last I heard, SGI expected to have cddi for the Indigo 2 Extreme
about 4Q93. Is it still expected within this timeframe? Cost??
Will this fit into the backplane of an Indigo 2 Extreme, or do the
graphics cards cover the ports?
--- 1 ---
The FDDI (fiber) board is now available. Twisted Pair FDDI will
likely be available around 4Q93, at least from an engineering stand
point! You'd have to contact your local sales person to see when those
wacky marketing folks intend to sell it. I'm not exactly sure what
it's cost will be.
>Will this fit into the backplane of an Indigo 2 Extreme, or do the
>graphics cards cover the ports?
The slot scheme on Indigo2 is confusing and goofy. You can have one
Extreme Graphics board set and one FDDI (or one FDDI-TP) board stuffed
at the same time. This maxes out the slots. You couldn't fit the
video option or any EISA cards in addition to Extreme and FDDI.
--- 2 ---
| The last I heard, SGI expected to have cddi for the Indigo 2 Extreme
| about 4Q93. Is it still expected within this timeframe? Cost??
Last I heard, it was still waiting for the standard to be approved.
That is either close, or just recently happened (I've lost track).
I haven't heard release date info.
| Will this fit into the backplane of an Indigo 2 Extreme, or do the
| graphics cards cover the ports?
It occupies the same amount of space as the fddi board for the Indigo2.
You can put Express graphics and fddi/cddi in the same system, but that
fills all the slots (no room for EISA or other GIO boards).
With XZ or XL graphics you would have room for an EISA card also,
but both GIO slots would be full.
(37) - Apple (or other) CD-ROM on SGI
---------------------------------------------------------------------------
There seem to be a few posts lately where people want to use CDROMs
with their beautiful Indigos etc. Because we're poor ;-< and can't
afford an Indigo, I need to mount a (iso9660?) CDROM drive on our
ol'faithful Iris 4D20/GT.
Because we're *really* poor, my colleagues would very much appreciate
it if this CDROM drive could also be used on our Macintoshes and PCs! -
not all at the same time though!
I'm sure someone else out there must have similar
requirements/limitations... how do you handle such a situation?
My thoughts were to get an Apple 300i (I have a Mac in my office!) to
kill at least two birds with one stone...
Will this work on the 4D/20 and Irix 3.3.1?? Any other suggestions?
--- 1 ---
Nobody has posted any success stories on this, although many have asked,
and some have tried. Aside from the fact that you really need the
SGI version to be able to install on old machines like the 4D/20, you
need the 512 byte sectorsize default, and that really upsets Macs.
I've yet to find a CD-ROM drive for the Mac that has a 'standard' enough
SCSI implementation to work on any SGI system, even those like the CD300
from Sony, which is supposed to be a fairly standard drive. Presumably
Mac's need some unique firmware changes in CD-ROM drives also, and it
just doesn't want to work.
(38) - Connecting Tektronix color printer to SCSI port
---------------------------------------------------------------------------
We have a 4D/310 VGX with no parallel port and a textronics color printer
with no serial port. Both have available SCSI ports, can we make them talk
in a short period of time? Our SA guy is fairly new, and not very optimistic.
I know we have 3 different SCSI printers tested, and 2 of them supported
at this time (Seiko and Genicom/SRS). The folks at Tektronix in their
printer group have been in fairly close touch with the Impressario folks
at SGI at various times, so why not ask your Tektronix support folks.
(39) - Disks for Challenge L
---------------------------------------------------------------------------
I am configuring a Challenger L with some Maxtor MXT-1240S drives. These
are jumper configureable single-ended/differential Fast SCSI-2 1.2 MB
(formatted) drives. (1) Other than the obvious need for SGI drive sleds to
allow power connection in the bays, are there things to look out for when
selecting a drive? (2) Is the above drive known to work? (3) What type drive
does SGI use by default for the 1 GB and 2 GB option?
I had some very bad experiences with the early 1240 firmware, in terms
of reliability (fixed pretty much, by the last version I tested) and
performance (not fixed by the time we gave up on them; don't know if it
was later or not).
I don't think the 1240 was ever tested against challenge at all.
The officially supported drives are OEM versions of the 1.2 and 2 GB
IBM drives.
(40) - Multichannel Option Problems
---------------------------------------------------------------------------
We just got an Multichannel Option board for our RE2 Onyx (with
two raster manager boards). So far we can't seem to get it to
go into the Multi-channel mode.
if we do gfxinfo, we get:
Graphics board 0 is "REV" graphics.
Managed (":0.0") 1280x1024
Display 1280x1024 @ 60Hz
12 GE (GE10 rev. 0x7)
2 RM boards
Medium pixel depth
10-bit RGBA pixels
Not using Multi-Channel Option
according to our reading of the MCO manual we should be able to simple
do something like:
setmon -S 2@1280x1024_60
and we get:
setmon: internal error in /usr/gfx/ucode/RE/vs2/vof/2rm/1@1280x1024_60/
vs2_vof0.u
several other settings were tried, all but a few gave the same error.
One that did sort of work was:
setmon -S 2@1200x900_72
but our monitors couldn't handle that (image wasn't syncing or sized right).
gfxinfo gave:
Graphics board 0 is "REV" graphics.
Managed (":0.0") 2400x900
MCO Display 0 1200x900 @ 72Hz, origin (0, 0)
MCO Display 1 1200x900 @ 72Hz, origin (1200, 0)
12 GE (GE10 rev. 0x7)
2 RM boards
Small pixel depth
10-bit RGBA pixels
Driving Multi-Channel Option
Anyone have any idea what we need to do to get the 2@1280x1024_60 to
work (when not in MCO mode our normal mode is 1280x1024_60, i.e. the
monitor(s) we want to drive are 1280x1024 at 60 Hz).
We could conceivably wait for our local SGI guy to come back from vacation,
but we'd like this to work soon.
--- 1 ---
You didn't say what version of software you are running. The message
above indicates that the file
"/usr/gfx/ucode/RE/vs2/vof/2rm/1@1280x1024_60/vs2_vof0.u" does not
match the version of Irix that your system is running. You would see
this if you were trying to load VOFs from 5.0.1 under 5.1 or vice
versa. You need have a matched set of VOF's. I would guess that the
following happened:
Your system is running 5.1 which already contains MCO support.
The SSE installed an MCO and loaded the 5.0.1 MCO software. This CD
only contains MCO vofs so it would not affect the system in any other
way. You now have a 5.1 system with MCO vofs from 5.0.1. Re-loading
eoe1.sw.unix from 5.1 should fix this problem.
--- 2 ---
Well we finally got it to work by copying the appropriate files
from another Onyx system. Seems our files were corrupt (not even
the same number of bytes in length).
Now for another question, when we put it into 2@1280x1024_60 mode we
do indeed get display on two monitors and each is 1280x1024.
Unfortunately as far as X is concerned this is being managed as
one large screen/display. That is, X treats this the whole thing
as :0.0 and it is 1280x2048 with the top half of this display on
the first monitor and the second half of the display on the second
monitor. This has undesirable artifacts, things like: the dogfight
is stretched out to cover boths displays (the scene on one monitor,
the instruments on the other, and the aspect ratio all wrong); the
initial login screen (pandora's box) is stretched across both
screens; etc.
This isn't really the way we want it (though I suppose we can live with
it for the application we bought the thing for). It would be much nicer
though if we could convince X that this is one display with two screens.
That is, have a :0.0 and a :0.1 with :0.0 on one monitor and :0.1 on
the other monitor, with each screen being 1280x1024.
Is there any way at all to do that?
--- 3 ---
>Well we finally got it to work by copying the appropriate files
>from another Onyx system. Seems our files were corrupt (not even
>the same number of bytes in length).
Either corrupt, or they were the older 5.0.1 vof files, which were
shorter in length than the 5.1 vof files.
>
>Now for another question, when we put it into 2@1280x1024_60 mode we
>do indeed get display on two monitors and each is 1280x1024.
>Unfortunately as far as X is concerned this is being managed as
>one large screen/display. That is, X treats this the whole thing
>as :0.0 and it is 1280x2048 with the top half of this display on
>the first monitor and the second half of the display on the second
>monitor. This has undesirable artifacts, things like: the dogfight
>is stretched out to cover boths displays (the scene on one monitor,
>the instruments on the other, and the aspect ratio all wrong); the
>initial login screen (pandora's box) is stretched across both
>screens; etc.
>
>This isn't really the way we want it (though I suppose we can live with
>it for the application we bought the thing for). It would be much nicer
>though if we could convince X that this is one display with two
>screens.
>That is, have a :0.0 and a :0.1 with :0.0 on one monitor and :0.1 on
>the other monitor, with each screen being 1280x1024.
>
>Is there any way at all to do that?
>
No; the problem is that the gfx device driver was not written to
support multiple screens per single graphics pipe. It is unlikely
to be changed to support this in the future.
Most applications which use the MCO can't afford the gfx context
switching overhead that they would incur when switching from screen
to screen anyway, so implementing the 'multiple screen per gfx pipe'
feature is a solution in search of a problem. Of course here at SGI,
I just sit down at the Onyx/MCO and start typing away into wsh's and
wish for the multiple screen X server too.
There is a solution, if you want to throw $$$ at it; you can order
a triple pipe server from SGI, and then you get :0.0, :0.1, :0.2.
Then you get the same problem all over again if you put MCO's in
each pipe :-)
(41) - Flicker on Indigo2
---------------------------------------------------------------------------
I've just setup an Indigo^2 XL (with the 19" monitor),
and the screen display has a strange flicker to it.
There is another large monitor in the same room,
but turning it off didn't affect the Indigo monitor.
I tried playing around with the adjustments on the monitor's
remote control, but nothing seemed to make a difference.
Has anyone else seen this?
--- 1 ---
Sounds like a timing problem with the prototype hardware. You might
try '/usr/gfx/setmon 60HZ' if so, to see if that helps. If you got a
demo unit or loaner early on, you might not have the late, but in the
MR released software, changes that are also needed.
I suppose it might also simply be a syncing up with flourescent
lights or the like; does it still occur with the lights off?
--- 2 ---
I did this and the flicker went away. Here's the session:
random 1# /usr/gfx/gfxinfo
Graphics board 0 is "NG1" graphics.
Managed (":0.0") 1280x1024
24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A
MC revision C, xmap9 revision A, cmap revision B,
bt445 revision A
Display 1280x1024 @ 72Hz, monitor id 9
random 2# /usr/gfx/setmon 60HZ
random 3# /usr/gfx/gfxinfo
Graphics board 0 is "NG1" graphics.
Managed (":0.0") 1280x1024
24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A
MC revision C, xmap9 revision A, cmap revision B,
bt445 revision A
Display 1280x1024 @ 60Hz, monitor id 9
random 4#
Is it possible to use a higher refresh rate on an Indigo^2 XL?
I thought it had the same graphics as the Indy, which is supposed
to use a refresh of >= 72Hz?
>I suppose it might also simply be a syncing up with flourescent
>lights or the like; does it still occur with the lights off?
No, turning off the lights didn't make a difference.
--- 3 ---
72, but not 76. As I said, it sounds like you have pre-MR hardware
and/or software. The MR stuff does work at 72.
--- 4 ---
On a similar note, is there a way to setup an r3k Indigo, with
IRIX 4.0.5F, to boot up in 72HZ video mode? I am currently using
a DEC 19" monitor that only syncs @ 72HZ and I must do an rlogin
and /etc/gfx/setmon 72HZ in order to see and use the console.
--- 5 ---
How can I track down whether it is a hardware or software problem?
Does this help?:
% uname -a
IRIX random 5.1.1 09101811 IP22 mips
% /usr/gfx/gfxinfo
Graphics board 0 is "NG1" graphics.
Managed (":0.0") 1280x1024
24 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A
MC revision C, xmap9 revision A, cmap revision B,
bt445 revision A
Display 1280x1024 @ 60Hz, monitor id 9
And one more question, is there some way to make 60Hz the default until
our hardware/software is updated. Right now, I have to re-set the mode
any time the system is rebooted. Is there a prom variable I can set?
(42) - Fuji M2263SA on an Indy?
---------------------------------------------------------------------------
Anybody sucessfully config a Fuji M2263SA 5.25" drive for
an indy? I have: SCSI-2,No Synchonous, rest factory defs.
and fx can ALMOST format it...
--- 1 ---
So what errors do you get? I might be able to suggest something
that would help.
--- 2 ---
Doesn't Indy support Fast-SCSI-synchronous-transfers?
--- 3 ---
Yeah, but Fujitsu doesn't ;) At least, if it is like the earlier
2263 drives, they don't handle the sync negotiation correctly. Maybe
that's been fixed...
--- 4 ---
Latest info on the Fuji M2263SA config:
drive is configred as:
External M2263SA drive, SCSI address 5
All manufacturer defaults
SCSI-1/CCS instead of SCSI-2
Synchronous mode disabled
connects to a Indigo R3000 Entry system IRIX 4.0.5F,
running:
% fx -x
does an AUTO mode just fine. Formats and verifys disk
with no problems or messages. Doing a mkfs on the
drive works like a charm.
Now physically remove the drive, connect to an Indy.
>>setenv tapedevice bootp()remotehost:/CDROM/dist/sa
>>boot -f $tapedevice(sashARCS) --m
ROM GUI reports:
copying installation tools to disk...
then
monitor console
request sense failed io failed...
Apparently there are some real problems with the SCSI
driver on an Indy, since this same drive and cable
works fine with:
NeXT systems (NEXTSTEP 3.0 and 3.1)
SUN sparcstation 1 systems (Solaris 2.0)
IRIS R3000 entry (IRIX 4.0.5F)
--- 5 ---
Note that Indy actually runs at sustained fast SCSI rates; Indigo does
not. Your cable may well be not be good enough. External cables are
strongly recommended to be as high quality as you can get (like ours
;)) and in no case longer than 2 meters. In any case, it clearly isn't
the same cable you used on Indigo, they have different connectors...
Of course, if sync mode is truly disabled (as opposed to perhaps
target initiated sync being disabled), then it isn't running at
fast scsi rates, but even so, cabling could be an issue, as you
can hose the internal drive since it is on the same SCSI bus.
--- 6 ---
So it should be possible to use a Fujitsu M2624FA (3,5", Fast-SCSI-2)
in synchronous-mode with the Indy. Right?
--- 7 ---
Fast SCSI works in Indy, no doubt about it. Whether that particular
drive will work, I can't say. I will say that people have had more
problems with Fujitsu SCSI drives on SGI equipment than most other
brand drives, for some reason.
--- 8 ---
While I profess to know nothing about the INDY ( the pricing structure
for them and the features my clients need adds up to a win for the
Indigo2 all the time ), some people seem to be having real problems
with Fujitsu disk drives on some SGI boxes.
The following models
2624-FA ... note *F* -> fast
2652-SA
2654-SA
2694-SA
should all work as FAST SCSI-2 drives, although some of the early
revisions of the 2652-SA had real problems related to caching, but
the fixes are reasonably readily available. The following models,
2263-SA
2266-SA
2624-SA
only work as standard SCSI-2 drives. They do work as SCSI-1/CCS but
that is not the issue here. In the area of caching, there were real
problems with the early firmware revisions of the first two models,
although Fujitsu is not alone in this area of SCSI firmware problems.
While some of this was caused by Fujitsu trying to pander to all the
sorts of peculiarities of machine makers ( they even had a special
revision of the firmware for the 2266 to make it behave on DEC
workstations ), the industry was still learning about SCSI-2 at that
time - most workstation vendors only offered SCSI-1/CCS then anyway,
and even then, they had problems getting their device drivers right.
For those who are using Fujitsu drives on SGI equipment, those
that have problems, and those that may not, I would suggest
posting to the group, the
- model number of the drive, and
- age of the drive,
- hardware revision level, and
- firmware revision level, and
- jumpers connections, and
- actual problem symptoms, and
- OS revision, and
- target machine, and
I would also be personally interested if you purchased the drive from
your local PC disk vendor or from somebody who actually knows something
about disk drives on high performance workstations. BTW, I have never
learnt or even understood what factory defaults are so I get lost when
people mention them and maybe many others do too. Unfortunately, when
talking about defaults, we are sometimes referring to what has been
delivered, as opposed to what the factory in Japan uses.
Maybe, with this set of results, it may become obvious, to the world at
large, what the problems really are.
(43) - 4D/25 Boot problem
---------------------------------------------------------------------------
I have a 4D/25 under my wing which has many problems... The system disk
developed bad sectors, and I tried to use fx to reformat, and do a
butterfly test to find bad sectors. It didn't report any errors, so I
tried to install a new system from the original install tapes for Irix 3.2.
Unfortunately, it wouldn't let me mount the /usr partition, saying that the
filesystem was dirty. I fsck'ed it, mkfs'ed it, and reformatted it, but
none of these helped. Now I can no longer access the fx program, and I
tried to boot off of the sash file, but I get an Invalid Byte Order
message. How can I reformat the drive now? I cannot access the fx, so I
cannot format. Any helpful hints?
Also, what kinds of upgrades are suggested for this system, or is it adding
fuel to a dead fire? The machine only has 8mb RAM, 340mb HD. Should I
just leave it as is, or is it worth upgrading?
It sounds to me like you repartitioned the drive accidentally, or did
/label/creat/all, or did a wr-cmp test in the wrong part of the disk.
You can boot fx from your installation media.
From the PROM monitor, try (assuming the tape is at ID #7, for the
sake of illustration):
tpsc(0,7)fx.IP6 -x
Faster graphics (a number of different options, although not all may
still be available), more RAM (up to 32 MB officially, 64
unofficially), zbuffer, upgrade to 4D/35 (basicly same cpu and
system architecture as r3k Indigo).
Probably about $10K US to go up to the fastest graphics and the 4D/35,
maybe even a bit more if you want to go to Elan, which the 35 supports,
but the 20 does not).
(44) - Maximum Memory on a 4D/25
---------------------------------------------------------------------------
I have a 4D/25 with 32 MB of RAM and understood that it was pretty much
filled to capacity. Unofficially, how can I upgrade it to 64MB?
Buy 4 MB SIMMs from one of the 3rd party vendors that knows SGI. The
reason it isn't supported officially is that some DRAM initializes to
all 1's, and some to all 0's, and the released PROM touches some memory
(with 4 MB SIMMs only) before clearing it, and so gets a parity error
if you use the "wrong" type. I believe the SIMMs with the Toshiba
DRAMs worked, but I won't swear to it.
(45) - Bru and M/O drives
---------------------------------------------------------------------------
Don't know about flopticals, but bru works well with magneto-optical
cartridges - very fast. When it hits the end of the media (290 Mbyte
per side) it gives an error message and asks you to insert the next
volume (i.e. turn the cartridge over) and then continues with the
second part of the archive on the second volume.
(46) - VME Transfer Problems
---------------------------------------------------------------------------
Help! I have a 3rd party VME board which acts as a bus master doing block
transfers to and from SGI main memory. The board worked fine when plugged
into a POWER SERIES 4D/340 system. We upgraded our 4D/340 to a Challenge L
and now the board crashes the Challenge. I've talked to several engeniers
around here (here is Brookhaven National Labratory) and they all tell me
("VME is VME and your borad should work in any VME bus which claims to
be a standard VME bus") The board does not crash the Challenge on single word
transfers, only block transfers. To be more specific, If the block transfer
involves more than 10 32 bit word tranfers, it crashes the system. If the
block transfer is less than or equal to 10 32 bit word transfers, The
Challenge does not crash. Could it be that SGI as come up with a 'higher
standard' in VME bus for there Challange machine and that my board adheres
to a 'lower standard?'
My question is, has anyone out there had similar problems with their
3rd party VME boards plugged into the Challange L? Is there any advice
that I can get from SGI about how to narrow down the problem so that
I can point my finger at either the Challange or 3rd party board?
One thing to note, this 3rd party board knows nothing about the 64bit
VME standard. If you try to do 64bit tranfers to and from the board,
this will crash the Challange. (But this should be of no concequence
since I believe that would be able to stick a 32bit VME board into a
64bit VME bus. Right?)
--- 1 ---
Here at Toshiba we found a problem where an Internally designed
VME board caused the SGI V35M DMA state machine to lock up when
a Bus request resulted in a null operation, IE it released the
bus right after getting bus grant.
This state is easy to see by (I think) watching bus grant on the
back plane, it will cycle endlessly with no other activity on the bus.
--- 2 ---
I'm following up to my posting of the Challenge crashing with my
3rd party VME board. It turns out that the SGI Challenge was at
fault. Our maintance man suggested replacing all our boards (The
CPU board, the IO4 board and the MEMORY board) with boards at the
latest revision level. When we did this big swap, the crashing problem
with our 3rd party VME board went away. I don't know what revision
levels our boards were at that caused this crash, or what revision
the curent boards are at, but what I does that our Challenge was
delivered to us in late June of '93 and we just made the board swap
this Wensday, Oct 13.
--- 3 ---
There is a known bug in the V35/V35M PIC1b arbiter that can cause
graphics crashes during VME transfer. We are working on the
resolution to this, but it looks as though we may have to add
the VMAX card as a work-around.
(47) - Pio_bcopyin and pio_bcopyout arguments
---------------------------------------------------------------------------
To anyone on the internet! Do you have the parameters which are given to
the subroutine pio_bcopy(). I have the Device Driver Programming manual
which describes this routine, but it does not give me any detail on the
parameters which are given to it. If you know, I'd be grateful if you would
let me know what they are.
See sys/pio.h. There is no pio_bcopy. There is a pio_bcopyin and
pio_bcopyout.
The 3 int args are size, itmsz, and flag. itmsz is 1,2,4, or 8, and
is the size in bytes of each object to be copied (and determines
whether the copy is a byte (8 bit), 16 bit, 32 bit, or 64 bit copy).
size is the number of *bytes* (not number of objects) to copy, and
must be a multiple of itmsz. flag is PIOMAP_* from pio.h
I'm not sure, but it looks like this might one place where a relatively
late change didn't make it into the driver guide, so the arguments
are different in the documentation.
(48) - DMA Rates on EISA & GIO
---------------------------------------------------------------------------
I'm trying to find a system that can copy data from memory to it's i/o
bus as fast as possible. I know that a SPARC IPX can copy to it's SBUS
at about 16megabyte/sec without using DMA and since there are only lousy
SBUS DMA controllers available I think this is all we can expect out of an
SBUS box. Does anyone know any different?
How about SGI? How fast can it move data to it's EISA bus (for indy or
the indigo)? Are there EISA cards that can DMA data out faster than the
CPU can copy it out there?
No EISA on Indy. But EISA rates on Indigo2 (Indy's big brother) are
right up near the max, if you are doing 32 bit transfers. I think
30 MB/sec if the gio bus runs at 33, and about 23 if it is running
at 25 (as it does with Extreme graphics).
GIO data rates can hit about 70% of theoretical, which means abyout
150 MB/sec on gio64, and about 75 on gio32.
This is with DMA of course. PIO is a *lot* slower.
(49) - SGI Periodic Table
---------------------------------------------------------------------------
You may acquire table of SGI products /sgi/93.13.7_Periodic_Table.ps.Z
via anonymous ftp from sgi.com
(50) - Quick Ring for Indy?
---------------------------------------------------------------------------
Has anyone heard of Quick-Ring being offered for the Indy? Quick-Ring
is a multimedia communication network developed by Apple and National.
It has just been announced (by National), I think; I hadn't heard
anything was shipping yet. I haven't heard any discussion at all about
ever doing it on SGI platforms.
(51) - Reading audio from CD-ROM drive into aiff file
---------------------------------------------------------------------------
Can anyone tell me where to get a program (pref anonymous ftp) that
will allow me to read audio CD's on the SGI's CD-ROM and sample it
into an aiff type file ?
I wanted to read the samples directly into the file without conversion to
analog if possible.
If you are running the IRIX OS version 4.0.5F or later, you will
find that you have the application "cdman" (/usr/sbin/cdman).
It lets you play audio CD's and also sample them into aifc files
which are pretty much the same as aiff files. If you really want
aiff files you can convert the aifc file using soundfiler or sfconvert.
(52) - Determining current video scan rate
---------------------------------------------------------------------------
Looking through the last Pipeline, I was wondering if we had our video
systems set to the 'best' vertical rate. I noticed that, while the default
for the SGI's is listed as 60Hz, our monitors (19" Mitsubishi) can handle up
to 130Hz. The setmon command may be used to change the rate, but short of
writing a GL program, there seems to be no way to find the *current*
setting.
Does anyone have a program to verify the current mode? Also, and I suspect
this would be so, wouldn't a 72Hz vertical rate on my hardware be better
(less flicker under florescent lights)? Any comments appreciated.
--- 1 ---
Unless you are using *extremely* expensive monitors, I'd be astounded
to hear that they could handle 130HZ non-interlaced.
| Does anyone have a program to verify the current mode? Also, and
| I suspect this would be so, wouldn't a 72Hz vertical rate on my
| hardware be better (less flicker under florescent lights)?
| Any comments appreciated.
It might; depends on whether your graphics support it. XS does. There
were also some monitors that didn't look too great at 72, as I recall.
The 'default' they were referring to, was for monitors without the
special cables that allow the system to figure out the monitor type,
if I'm not mistaken
--- 2 ---
Try 'osview -i1'.
The value displayed in the 'Graphics,gintr' field is
approximately the vertical refresh rate.
(53) - Using Vigra MMI-210 in a 4D/320S
---------------------------------------------------------------------------
I'm evaluating a MMI-210 for an SGI 320S. The board is in
and I can access on board memory from the host but I can't
seem to make the interrupt stuff work.
I have used the mmi-210 on SGI systems. I have not tried interrupts,
however. You may want to check obvious things, however. For instance
make sure that vme jumpers are in place for every slot skipped if the
board is not in the leftmost available vme slot.
I suggest contacting Vigra (619)597-7080 if you continue to have
difficulties.
(54) - Software upgrade required for R4400?
---------------------------------------------------------------------------
recently ordered a R4400 upgrade for a Silicon Graphics Crimson Elan
workstation. Is IRIX 4.0.5 compatible with the R4400? Will I have to
switch to IRIX 5.0.1?
I believe you will need a new one called 4.0.5J. Your service office
should be able to provide it to you when needed (or it will come
with the upgrade).
(55) - FDDI in Indigo2
---------------------------------------------------------------------------
We just received an FDDI card for our Indigo2. The instruction say to
move the Extreme cardset up one slot, and install the FDDI card in the
bottom GIO slot. When we do this, we lose our graphics (so far, the
hotline has been no help).
Has anyone been able to make this work? If we do get it to work, can
we install a Galileo card in the same system?
--- 1 ---
Sounds like you have a very early demo unit, and/or very early alpha
software. If so, you'll have to get it upgraded.
| Has anyone been able to make this work? Ifg we do get it to work, can
| we install a Galileo card in the same system?
Obviously it works, or we wouldn't have shipped it... We may be
somewhat careless at times, but not *that* careless.
--- 2 ---
Pre-production Extreme graphics board sets only worked in the
bottom slot. These boards were not supposed to be shipped to
any customers. It sounds like maybe you have one of these.
You should contact your local support person ASAP.
>Has anyone been able to make this work? Ifg we do get it to work, can
>we install a Galileo card in the same system?
If you have FDDI and Extreme in the same machine, then there is no room
for Galileo. Sorry. This is a sore point among many engineers here...
There are ways of getting FDDI and video in an Indigo2 while
sacrificing some graphics performance.. You should talk to your
local sales person as I'm not sure what's been announced and what's
shipping.
(56) - 1024x768 support with Elan for projector
---------------------------------------------------------------------------
We have an Indigo R4K Elan system (4.0.5f) which we would like to use
with a VGA Barco projector. On reading the Sept/Oct PIPELINE,
they indicate that Elan's will support 1024x768 graphics by
using "setmon IRIS3K". When I try this, I get something like,
"format unsupported".
I "borrowed" a copy of setmon from 4.0.5h, including the ucode
files, and tried it again. Still no luck. What do I have to do
to make the Pipeline article right?
--- 1 ---
> they indicate that Elan's will support 1024x768 graphics
/usr/gfx/setmon iris3k works on an Elan here under 5.1.
I don't know about 4.x.x.
> I "borrowed" a copy of setmon from 4.0.5h,
DON'T DO THIS. You cannot mix-and-match microcode files between
releases of the operating system. (The kernel and other bits of
the graphics software are intimately tied to the VOF files).
--- 2 ---
>/usr/gfx/setmon iris3k works on an Elan here under 5.1.
>I don't know about 4.x.x.
When will this be available to the general public. I'm having
the same problems. I need to get the IRIS3K and/or the 30HZ mode
working on my Indigo. The ucode files for these modes were not
included in the general distribution of the op-sys, but everyone
I've talked to at SGI thinks that they are, and can't understand
why this doesn't work on my machine. It seems like all the
machines at SGI have workiing versions of these modes, but not
the machines in the field.
(57) - Reading data from DAT with a program
---------------------------------------------------------------------------
I'm looking for pointers to information that will tell me how to read
data from an Indigo internal DAT tape drive under program control.
I'm an engineer working on a DSP/data analysis project. The lab
digitizes their observations on DAT tape and my job is to write a
system to reduce and analyze it. The current method is to play back
the tape on a high-fidelity audio recorder, digitize the data on a PC,
ftp it to a Sun, resample it to 48K (because the PC sampling board has
a screwball clock), and then run the DSP programs (which must run on
the Sun because they're far too big to run under MSDOS).
Having read this far, you can imagine my joy at discovering an
under-used Indigo with a built-in DAT tape and a large hard-disk.
Visions of a seamlessly integrated all-in-one, from-tape-to-report,
no-additional-noise-from-redigitizing application danced through my
head --- only to be cruelly dashed when I discovered that there was
absolutely no documentation on how to control the tape-drive or read
data under program control.
My requirements are simple. I *must* control the tape drive because I
haven't (and will never have) enough disk to read and process an
entire DAT tape all at once.
In practice, I face two situations:
(1) If I'm very lucky (and the lab staff observed the experiment and
noted the time of *all* of the "interesting" events), all I have to do
is spool the tape to a few selected spots, read the data from each
event into an appropriate buffer, and process it.
(2) If I'm not lucky, I need to read the entire tape buffer-by-buffer,
look for events in software, and then process them when they are
found. (This is the normal case.)
In either case, I will have to read (both channels), fast-forward, and
rewind the tape and read the time-code in order either to find the
events (if I have approximate times) or determine the time (if I find
an un-recognized event).
This can't be the first time this has been done and I can't be the
only engineer who's had trouble finding the documentation. I'd love a
pointer to documentation, example code, FAQ, or (dare I hope?) the
name or ftp location of some archive containing a package that already
does exactly this sort of thing. (Right now, I'd settle for the right
subject for a man page. I've tried all the ones I can think of.) I
don't care whether the package is public-domain or commercial (my
project has a budget) as long as it can be customized to meet my
needs. (But my experience is that PD is better in this regard.)
Suggestions, comments, and criticisms are welcome. Please feel free
to flame at me to RTFM, but please also tell me where in TFM to R.
(Please also tell me which FM it is, so I can make sure we have it or
order it if we don't.)
Try 'man datframe dtintro' as a starting point. Or just use
datman and record to file function to get an AIFC file with
the data.
apropos 'dat' does a good job of finding these (assuming you have
installed the digital media libraries).
| My requirements are simple. I *must* control the tape drive because I
| haven't (and will never have) enough disk to read and process an
| entire DAT tape all at once.
datman will do still do the job, as long as you have some kind of
timecode; you can select the timecode to seek to, and you can
stop the 'record to file' manually. Not as elegant as doing it
under program control, but a lot simpler to get started ;)
| Suggestions, comments, and criticisms are welcome. Please feel free
| to flame at me to RTFM, but please also tell me where in TFM to R.
| (Please also tell me which FM it is, so I can make sure we have it or
| order it if we don't.)
Assuming you have 405F or the Indigo Patch, you want the dmdev
product (seperate from the IDO). In 5.1, I think it is part of
IDO, but I'm not positive.
(58) - Replacement Indigo Keyboard?
---------------------------------------------------------------------------
Can anyone suggest a source for a replacement Indigo keyboard and
mouse? I am trying to find something cheaper than the spare parts SGI
sells (total for the two is approx. $500 from SGI). Can I use a PC or
Mac keyboard & mouse? If someone can send me specs and pinouts, I'll
hack together my own cable...
--- 1 ---
Nope. Only Indigo2 and Indy can use PC keyboards. man serial
keyboard mouse gives pinouts, etc. Good luck...
--- 2 ---
There's a surplus place in the bay area which had a pile of SG
keyboards last time I was in CA-- I think they wanted about $50.
for them. Sorry I don't remember the name and I'm pretty far from
there at the moment, but maybe some kind reader can fill in the
blanks. The place is just across the street from the Sunnyvale Fry's.
--- 3 ---
Weird Stuff; several outlets around the SF Bay Area. stock
varies tremendously with time, but almost always interesting...
Most of it isn't guaranteed to work (there are significant
exceptions), and is sold "as is".
(59) - Can't find tape drive on 4D/35
---------------------------------------------------------------------------
we have a problem with our SGI QIC 150 tape drive in our SGI 4D/35 TG
running IRIX 4.04. After we had reinstalled our tape drive back in
the system (we have used it in another machine for a while). All seems
to be alright, hinv shows the device :
Tape drive: unit 2 on SCSI controller 0: QIC 150
and the confidence test was also alright. But if I use for example
comand tar tv, the following error message appears :
tar: /dev/tape: No such device
Could somebody help me, because we are confused and do not know
what we can do ? Please mail me your informations.
If tar is not given a specific tape device name it uses /dev/tape
which is a link to some specific tape device. To figure out which
tape device the system thinks is '/dev/tape', do the following:
ls -li /dev/tape
You'll get something like this (this is from my system):
725 crw-rw-rw- 1 root sys 144,704 Oct 8 16:44 /dev/tape
---
Pay attention to the minor device number --^ , then type
ls -li /dev/mt/tps* | grep 704
What I got was:
727 crw-rw-rw- 1 root sys 144,704 Oct 8 16:06
/dev/mt/tps1d6
420 crw-rw-rw- 1 root sys 144,704 Oct 4 16:00
/dev/mt/tps1d6s
Which shows that SCSI ID 6 on the second SCSI bus (I'm running
an Indigo2) is the device linked to /dev/tape.
My guess is that one of the following things is happening:
/dev/tape is linked to some device that doesn't
exist (for instance if the SCSI ID was changed when used
on the other system). If this is the case, linking
/dev/tape to the proper device in /dev/mt would
solve the problem.
You've rebooted and reconfigured the system since you
removed the tape drive. This might have caused the
system to remove the tape devices. To remedy this,
do "MAKEDEV tape" as root.
Of course, if you want to check out the drive without doing any
of that use the 'f' option of tar:
tar tvf /dev/mt/tps0d2
That ought to work.
(60) - Will 525 MB tapes work in QIC 150 drives?
---------------------------------------------------------------------------
I was wondering if it was possible to use a 525 MB
tape in our QIC 150 tape drive. Has anyone tried that?
Will I be able to use it all instead of only 150 MB?
No, it won't work. Different tape formulation. If capacity
is what you need, the DC6250 tapes are just longer versions
of the 6150's, and will get you near 250 MB, rather than 150.
The newer QIC1000 drives can read and write the 525 and 325, as
well as all the QIC-150 media, and the QIC1000 media.
(61) - Second SCSI bus for Indigo?
---------------------------------------------------------------------------
I was wondering if anyone (Hello, Dave :-) ) knew if there was a
second plug-in SCSI card for the GIO bus that would work on an Indigo
R4000? If so, does the generic SCSI driver work with it? I need to isolate
a SCSI device on its own bus, because of some slightly non-standard behavior,
and it will need its own driver. It's not a hard drive or storage device,
it's actually a piece of data acquisition hardware. If you know of a card,
any guess on pricing? Thanks, and I will contact SGI Express or sales rep
as well, but they wouldn't know about the generic SCSI driver :)
Nothing available. There has been some work on prototypes, but I don't
know if it will ever be made into a product. devscsi did work on the
prototypes, and would presumably work on anything made into a product.
If it were done, it would probably be about the same price as the GIO
ethernet card for Indigo (I don't know what the price on that is).
(62) - Audio programming on Indigo2 (applies to Indigo and Indy as well)
---------------------------------------------------------------------------
I would like to do some programming of the audio-interface of a
SGI (indigo^2) in C. Therefore I would need any introduction on how
to use the audio-device, the audio input and output ports, the DSP, etc...
Does anyone of you know of any books, papers, etc. covering those topics?
Ask your salesman for the Digital Media Developer's CDROM 1.2, for a
myriad of audio libraries, example source code and documentation.
(63) - Audio programming - part 2
---------------------------------------------------------------------------
We are currently working on a project that involves real-time signal
processing on sound. As the SGI Indy both has a fast processor and
high quality sound in/out, we would like to utilize this, and use
it as a platform for our application.
The only example programs I could find here at the University's Indies
were in /usr/people/4Dgifts/devaudio. These use the /dev/audio device
directly, but there must be some more support for audio playback, like
channels ? Or do I have to multiplex and scale manaully, if I want to
play several sounds at different volumes simultanously ? I cannot use
the high-level audio tools, since we have to do sampling, processing
and playback in real time.
The manual pages refers to some other source code which is not
installed here, like audio/playaifc.c. I would be grateful if somebody
could send me some of those, as well as the part of manual section
that deals with audio subroutines (not commands), which we don't have.
I have compared the /usr/include/sys/audio.h file on Indigo and Indy,
and the one on Indigo states many more calls and options.
Does this mean that source code using audio for Indigo is not
compatible with Indy ?
To get started, it would be convenient to have an example program that
samples from line in, and outputs to line out. If anybody has
something like this, please send it to me. I would also be grateful
for any other spesifications or tips on how to use the low level
support of the audio system on Indy.
You need to get the Audio Library (AL) which is part of the Digital
Media Developers Option. You will also need the Irix Developers
Option if you do not have it already.
(64) - Power Connections for SGI systems
---------------------------------------------------------------------------
Could someone let me know the type of power (amps) and socket style
(twist-lock, etc.) connections required for the following machines. In
other words, what kind of "plug" do I need to make these things work.
4D 420 Single Tower
4D 340 Twin Tower
4D 210 Twin Tower
Onyx/2 Deskside
Onyx/2 Rack (terminator chassis)
--- 1 ---
4D 420 Single Tower
20 Amp Recepticle looks like -| |
o
and it's name is "NEMA 5-20R"
but the plug is called a NEMA 5-20P
4D 340 Twin Tower "same as above"
4D 210 Twin Tower "same as above"
Onyx/2 Deskside depends either 20 amp 120 volt like above
in minimal configurations.
or a 220 volt recepticle like this | -
o
but it real name is "NAME 6-20R
and the plug is called NAME 6-20P
Onyx/2 Rack (terminator chassis)
OHH, Well the single phase receptical is a HUB-330R6W which
looks kinda like the plug your boat might have if you paid
more than $30,000 for it. and the plug's name is
IEC 309,2-P,3-W,30A,250V but we call him harvey for short.
and the three phase plug is called a IEC 309,3-P,4-W,30A,250V
and plugs into a HUB-430R9W which looks like the plug on your
boat if your boat had an electric crane which picked up cars
or something.
(65) - Maxtor 8760E drive on 4D/240S
---------------------------------------------------------------------------
We have an SGI 4D/240S with an ESDI controller and a single drive.
We have recently aquired several Maxtor 8760E drives with their own power
supplies sold by Aviv which were originally on a VAXstation.
We would like to add these drives to our SGI, however we are having a problem.
We first removed the terminator from the drive which was already installed in
the SGI, and left the terminator in the single Maxtor that we were adding as a
test. The preinstalled drive was set to ID 0 and the new one to ID 1.
We then started fx in the extended mode, chose the ESDI controller,
drive number 1, and identified it as a Maxtor-8760E (number 30 on our version
of fx). We then attempted to format the disk using the 'auto' option, and the
format stage seemed to work, however, once it began excercising the disk,
it generated errors such as this:
ips0d1s10: sector not found (code 29) chs/4/2/40...about to do first retry.
ips0d1s10: sector not found (code 29) chs/4/2/40...about to do second retry.
ips0d1s10: sector not found (code 29) chs/4/2/40...about to do third retry.
fx/auto/complete I/O error - write error at block 4/2/40 (3348)
adding bad block 4/2/0
this continued until fx encountered enough errors to ask if it should
continue. When we tried excercising it sequentially, it seemed to find that
there was at least one bad sector in each track, thus adding it to the bad
block list.
We are at a loss as what to do next, and were wondering if anyone had
experience with these types of drives, or similar errors in 'fx'.
Incidentally, the one possibility that we thought of is an error in terms
of selectable options through jumpers on the drive. It is set to 'hard sector
mode' with 'ESDI programmable sector size' enabled. I'm not sure if changing
this is the answer, and I grow tired of random changes trying to get this to
work!
This takes me back about 4 years. Talk about nostalgia!
The Maxtor drive never did work very well on the ESDI controller.
About the only thing I can suggest it to choose the 'other' drive
parameters and play with gap sizes -- not very useful information,
I know. Unfortunately, the drive was always quite persnickety with
this controller, which is why we never sold it. We did supply the
parameters for it, though, in case others wanted to try to use it.
The 780MB drives we shipped were the Hitachi DK515-78 and Seagate
(or CDC) Wren 6.
(66) - Panic crashes
---------------------------------------------------------------------------
since 11 month we have an Crimson Reality Engine. There are two harddisks
installed inside. One harddisk and a cdrom are connected to first of the
two external scsi-ports. A dat-tape-drive is connected to the second one.
The cables of the first port are around 2 Meters, the second around 1 Meters.
I think there are no to long:
Since 2 Weeks the system
crashes with the following output:
PANIC : IRIX killed due to MP Bus Timeout
PC: 0x80009F4A4 ep: 0x80111DC0 Physical Address 0x17000700
DOUBLE PANIC: ....
Any tips or suggestions ?
Since I haven't seen any other replies...
Use dbx or dis on the kernel to check where that PC is (what
kernel routine). If it happens repeatedly, is it always
at the same PC?
Sounds like something is making a bad access.
Also, what changed in the hardware or software about the time
you started seeing the problem, if anything?
(67) - Swap space or RAM?
---------------------------------------------------------------------------
I have a few questions about using swap space instead of RAM. The system
I am using is an Indigo^2 with 32Mb of ram and 1.5Gb of hard drive space.
I will be upgrading to 64Mb shortly, but need to do some large memory
intesive calculations now. How does using swap effect the lifetime of the
hard drive? Is 1Mb of swap equivalent to 1Mb of ram. I know the swap runs
slower, but how much slower? The programs I will need to run will take
aproximately 6 hours each to run, but I will eventually need to run a few
that may take a couple of weeks. Should I go ahead and use the swap or
wait until I upgrade to the 64Mb of ram?
Disk speed is about 2 orders of magnitude slower than memory. If you
have the time to wait...
You really don't want to run programs that page heavily for long
periods, given any choice at all. It certainly won't hurt the disk,
but it is rather hard on your patience!
The disk is, after all, designed to be used ;)
(68) - Help with Exabyte 8505 tape drive
---------------------------------------------------------------------------
I need some help with an 8505 Exabyte tape drive.
I need drivers. I have it on my system but it will not read any of
my old 8200 tapes!!
--- 1 ---
No, you do not need drivers. The necessary drivers are already in the
kernel code libraries and most likely are already in your kernel.
What you may be missing are character special device files. You want
a set that allows you to specify to the tape drivers in the kernel
that you want to use your tape drive in low-density (a.k.a. 8200 mode).
And, you should also have the means at hand to make those as well.
Do you have a MAKEDEV shell script in /dev? If so, /dev/MAKEDEV tps,
should create the necessary character special device files for you if
you have the device properly installed on your system before you execute
the MAKEDEV shell script.
Character special device files are not drivers.
Whenever you install a new device on your system, it is most likely a
good idea to run /dev/MAKEDEV without arguments.
--- 2 ---
|No, you do not need drivers.
Well, not exactly. For reading, any old generic entry from tpsc
should do the trick, since the 8505 will sense the tape density
(i.e. the type of 8200/8500/8505/8500c drive format)
For writing, the mode select for the desired density will be required
unless the default is OK. If this is the case, then a simple mod to
tpsc will be required. Then a reconfig to make all this complete.
|The necessary drivers are already in the
|kernel code libraries and most likely are already in your kernel.
Again, not likely. I think the tpsc only includes 8200 and 8500, if
I remember correctly.
|
|What you may be missing are character special device files. You want
|a set that allows you to specify to the tape drivers in the kernel
|that you want to use your tape drive in low-density (a.k.a. 8200 mode).
|
Here's the actual scoop. It won't be density on read (the Exabyte
ignores and mode_select density stuff on read), but the swap/no
swap is most likely what is needed. For example, maybe try dd,
then conv=swab to see if that is the problem. Otherwise, make sure
that there is an appropriate entry in tpsc, and that the special
file has the (minor) bit set for the desired swap/no swap.
|And, you should also have the means at hand to make those as well.
|
|Do you have a MAKEDEV shell script in /dev? If so, /dev/MAKEDEV tps,
|should create the necessary character special device files for you if
|you have the device properly installed on your system before you
|execute the MAKEDEV shell script.
And there's the rub. If hinv responds with
Device: unknown
then the MAKEDEV script will not create the appropriate special
files. Once again, depending on the way that tpsc was modified,
then an appropriate modification to MAKEDEV will be required.
Otherwise, just do a mknod for the necessary /dev/rmt specials.
|
|Character special device files are not drivers.
|
|Whenever you install a new device on your system, it is most likely a
|good idea to run /dev/MAKEDEV without arguments.
hope these few ideas help clarify... I have the 8505 running on four
Indigos here, and have the mods for tpsc and MAKEDEV, as well as a
program I wrote to querry the drive to determine compression
performance. If anyone is interested, I'd be happy to share
(a number of folks have asked for this stuff, and it is working
for them)
(69) - Indy Third Party Drive Problems
---------------------------------------------------------------------------
We have recently purchased a number of INDY's (PC's and SC's) and are having
a lot of problems with various third party peripherals.
The problems seem to arise on systems with say one fast SCSI drive and one
standard SCSI drive. As an example I currently have a PC running IRIX 5.1.1
with a Seagate 450MB fast SCSI drive internal (device 1) and an external
Quantum 207MB standard SCSI drive (device 3).
At boottime a diagnostic window appears and complains about a lack of response
from SCSI id 4 and does a SCSI Bus Reset. The system continues to boot.
Once I have logged in I was under the assumption that I would see and unnamed
disk icon on the desktop - there isn't one.
I run "fx" and tell it that I am interested in SCSI id 3 and it gets an
I/O error and the SCSI bus gets reset.
I have used a standard SCSI drive on an SC already (no internal drive) so I
assume that standard SCSI drives are fine.
Is it simply the combination of fast and standard SCSI drives that causes
problems or is there more to it than that?
--- 1 ---
| from SCSI id 4 and does a SCSI Bus Reset. The system continues to
| boot.
This almost certainly means that the Quantum drive is botching sync
negotiations. Try editing /var/sysgen/master.d/wd93 to disable sync
on SCSI ID #3. The irix 5.1.x (for some x > 1) should report this
particular error a bit better.
| I run "fx" and tell it that I am interested in SCSI id 3 and it
| gets an I/O error and the SCSI bus gets reset.
Probably sync again.
| I have used a standard SCSI drive on an SC already (no internal
| drive) so I assume that standard SCSI drives are fine.
Almost certainly has nothing to do with PC vs SC. Also check to be
sure that you have active termination (no terminator in the drive),
and *good* cables, and that total cable length is < 3 meters.
--- 2 ---
>and *good* cables, and that total cable length is < 3 meters.
I found this in "relnotes impr_desktop 3", and have not seen it
anywhere else. Seems like kind of a strange place for such an
important bit of information for us SCSI device types. Anyway,
in the second bullet item, it reads:
o On Indy systems, there is currently a 2m (6 foot)
maximum cable length limit on SCSI devices instead of
the normal 6m (18 foot) maximum cable length. If you
experience "SCSI Bus Reset" problems, try a shorter
SCSI cable.
--- 3 ---
| in the second bullet item, it reads:
It is there for the SGI SCSI printer (which we OEM'ed; I think it is
now being supported by Genicom directlry). It should also be in
the Indy owner's guide.
(70) - R2000A/R3000 - What does this mean?
---------------------------------------------------------------------------
When I run "hinv" on our 4D/340VGX Power Series machine, it says this about the
processors:
4 33 MHZ IP7 Processors
FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 3.0
CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0
What does R2000A/R3000 mean? How can I tell whether it's R2000A or R3000?
>What does R2000A/R3000 mean?
It means that the processor uses the R2000A/R3000 instruction set.
>How can I tell whether it's R2000A or R3000?
From looking at the hinv output it could be ambiguous, unless you just
"know" these things. You could just look at the chip itself, but that
might void various support warranties regarding user serviceable parts.
This is an approx MIPS family breakdown based on cpu board type numbers:
R2000 - IP4
R3000 - IP5,7,9,12
R4000 - IP17,19,20,22
(71) - Heat problems with Seagate Barracuda in an R4000 Indigo?
---------------------------------------------------------------------------
I'm planning to install a Seagate Baracuda 2 disk drive in an R4000
indigo and I've heard rumours of possible heat problems - can anyone
clarify this? The Indigo in question has an elan card and a single
400Mb (approx) system disk drive, the other two 3 1/2" slots are
currently vacant - am I likely to have problems?
There were concerns that there might be heat problems (not enough
air flow), but so far, that appears to not be the case for Indigo2 in
some preliminary work. I don't know if that drive will be officially
qualified or not.
I don't know if any qualification work is being done on Indigo or not.
Certainly airflow is lower in Indigo around the drives. I'd keep a
close eye (finger) on the drive temperature.
(72) - Optical Disk Drive suggestions?
---------------------------------------------------------------------------
Our lab is thinking of getting an optical disk drive. We
would like to get one with a large-ish capacity (around 2Gb)
if possible. So, I guess I'm begging for any advice on price
and quality for such a disk drive.
We are using a fast Hewlett-Packard mechanism in a third party
packaged drive as an external on an Indigo R4K, and are happy with
it. The 5.5 inch media does 590 Mbyte with 512 byte/sectors -
necessary for SGI machines (don't get the alternative 1024
byte/sector media).
This is a 'standard' format that works in many drives. You have
290 Mbytes on each side of the disk. There are higher (less
standard) densities eg Tahiti,and I have recently seen other
1.2 Gbyte media 5.5 inch drives.
However, check the price of the media. The standard 590 Mbyte
disks cost much less than $100, while double density media can
cost 3-4 times as much. You will want more disks than you imagine,
since it is so easy to use it for various backups, copies etc.
We even use it over ethernet for backups of our Macs, and already
have 20 disks - 12 Gbyte! Make sure you get one of the
much faster split-optic head drives.
(73) - Moving a drive from one machine to another
---------------------------------------------------------------------------
I will be getting more diskspace, and I will want to move an external scsi
drive from one machine to another. I want to keep all the data that is on this
external drive.
Question:
Can I just move it to another machine and all the data will be there. Or do
I need (I will do it anyway, but...) to do a backup of it before I remove it
from the current machine.
My suspicion is that I must do a backup of it then reinstall it on the disk
after it gets added to the new machine. Is this true?
--- 1 ---
Assuming it is from one SGI system to another, you should be able to
just move it, but I'd certainly be paranoid and back it up first, if
you care about any of the data (you might have a head crash, or
might make a mistake while doing the setup on the second machine).
Also, if it is the system disk, and the machines are different types,
or different graphics, you might have to reinstall parts of eoe1 and
eoe2 with 'set neweroverride' in inst.
--- 2 ---
If the machine being moved to is of the same type of system, running
the same O/S (more or less), you should be able to plug the drive and
it should work. (You may have to dither with the SCSI address and
/etc/fstab and so on.)
If you are moving drives between non-compatable systems (say a Sun to a
SGI), then yes, you will have to re-format the disk and start with
fresh file systems -- SunOS has a different idea of what a hard disk
looks like (system label, partitioning info, file system layout, format
of the superblocks, etc.) from IRIX (or Ultrix, etc.).
(74) - IO4 Bus arbitration question
---------------------------------------------------------------------------
I was interested in the IO4 bus arbitration logic. Besides the
general description, does SCSI controler 0 have and advantage over
SCSI controler 1 ??
Not that I know of, in practice. One of the challenge folks may be
able to reply with more assurance.
(75) - Disk drive problem with Indigo
---------------------------------------------------------------------------
Recently I installed a DEC DSP3105 in an Indigo R3000. Everything
seemed to be working fine, until today when I tried to use the
internal 3.5 inch floppy... msdosd gave me errors when I started it. I
used hinv to see what it had to say:
1 33 MHZ IP12 Processor
FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 4.0
CPU: MIPS R2000A/R3000 Processor Chip Revision: 3.0
On-board serial ports: 2
Data cache size: 32 Kbytes
Instruction cache size: 32 Kbytes
Main memory size: 24 Mbytes
Integral Ethernet: ec0, version 0
Disk drive: unit 7 on SCSI controller 0
Disk drive: unit 6 on SCSI controller 0
Disk drive: unit 5 on SCSI controller 0
Disk drive: unit 4 on SCSI controller 0
Disk drive: unit 3 on SCSI controller 0
Disk drive: unit 2 on SCSI controller 0
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 0: Version WD33C93A, revision 9
Iris Audio Processor: revision 3
Graphics board: LG1
Yikes!!! I only have 1 disk, at unit 1, and one floppy at unit 3. Why
all these other phantom disks? I wouldn't mind if they were REAL, but
this is kind of annoying! Could anyone shed some light on this?
This symptom indicates that the device is addressed as 0. When a
disk is addressed at zero, it can sometimes be seen at every address,
because when the host adapter asserts its ID bit during selection,
the disk thinks it's being selected too.
(76) - Print problems with LaserWriter Pro
---------------------------------------------------------------------------
Don't point me at "man serial". I've been there.
My problem is a little more specific. I have a LaserWriter Pro 600
with a serial DB-9 connector running to an R3000 Indigo (with a DIN-8
connector). I have been able to access the printer using the ttyd* but
I want to get at least XON/XOFF control so ttym* is needed. With the
cable that I have, I can talk directly to the printer using ttym* and
kermit but, when I use ttym* in the printcap, files just disappear and
the printer never starts processing (as indicated by the flashing light).
If you have managed this, can you describe in detail your cabling?
Hardware handshaking using ttyf* would be even better but I don't think
the printer will talk RTS/CTS.
My cable looks like this:
DIN-8 DB-9 (according to LW manual)
DTR 1 ----------------------------- 1 DCD
CTS 2 8 CTS
TxD 3 ----------------------------- 2 RxD
SGnd 4 --------------+-------------- 5 SGnd
RxD 5 ------------- | ------------- 3 TxD
RTS 6 | 7 RTS
DCD 7 ------------- | ------------- 4 DTR
SGnd 8 --------------+
6 DSR
9 Ring
I fear that I need to drag some of the other pins high/low in order
to avoid floating lines but I don't know precisely what to do.
NOTE: I have set the configuration on the printer to use XON/XOFF, 8None,
at 9600 (setting 0), checking it through a Mac connected to the LocalTalk
port.
If you want XON/XOFF, then ttyd# is just fine. You almost certainly
don't want the modem signals (unless you tend to power your printer
off a lot), so it is either ttyd or ttyf.
| the printer never starts processing (as indicated by the flashing
| light).
That sounds pretty weird, as it indicates that the job is either
being scrapped, or that the spooler thinks it printed it OK.
Are your tty[mf]# devices owned by lp? Are there messages in
~lp/log?
Your pinout below looks reasonable.
(77) - NFS performance problems on 4D/35
---------------------------------------------------------------------------
We are experiencing some performance problems on our Model 35 NFS server.
One of the symptoms is that there appears (osview, sysmeter et al) to be
4 - 10 times as many packets comming in as going out.
A "sniffer" on the net seems to indicate that the SGI is actually processing
each and every packet on the net.
Can an ethernet interface get "stuck" in promiscuous mode?
We're running IRIX 4.0.5. Another 2 SGI's on the same net (one also running
the same release of IRIX) do not show this high number of input packets.
| We are experiencing some performance problems on our Model 35 NFS
| server. One of the symptoms is that there appears (osview,
| sysmeter et al) to be 4 - 10 times as many packets comming in
| as going out.
Not unreasonable, for many things. Particularly if you have an
app (or system) out there doing lots of broadcast or multicast
packets.
| A "sniffer" on the net seems to indicate that the SGI is actually
| processing each and every packet on the net.
Sounds like you have the somewhat bogus patch installed (posted here
many months ago) that permanently puts the 4D/35 in promiscuous mode.
I'd check your startup scripts.
| Can an ethernet interface get "stuck" in promiscuous mode?
Yes; it isn't stuck though, it is done deliberately (for snooping,
or the like).
(78) - Indigo Environmental Operating conditions
---------------------------------------------------------------------------
While most people operate their computers in the comfort of a machine room or
offices, we take them up flying !!
Our intent is to use Indigo computers for airborne experiments (not allowed to
tell you too much about them). This means they will be subject to pretty nasty
vibrations, accelerations and temperature variations.
Can anyone comment on the environmental envelope (accelerations, temperature
extremes) within which Indigo computers are expected to operate properly?
Silicon Graphics' technical reports don't specify anything about that (which
is not entirely surprising :-)).
--- 1 ---
Actually, those things *are* spec'ed. I think they were in the owner's
guide. This question has come up before, and vibration and temperature
changes (rate of change, and endpoint temperature) for the disk are
usually the biggest issue. If the cabin isn't presurized, you'll have
even more problems.
--- 2 ---
We actually have put several SGI machines on VME boards for "embedded
systems" applications; this might be better for your needs than
strapping a purple box in with a seat belt. I'm pretty sure at least
one Indigo variant is available. I don't have much information about
these systems; you may want to check with your sales rep.
(79) - Apple CD-ROM - Part 2 [see (37)]
---------------------------------------------------------------------------
I'm presently a Mac and Iris 4D user. The Macs are used in my office
and at home while the Irises are used in my lab. In the short term I
need a CD ROM player at home and am considering the Apple CD 300.
However, I may in mid or late '94 dump my home Mac in favor of an
SGI Iris.
Will the Apple CD 300 work on an Iris (including for software
installation)?
I've had many people ask, but only a few people try. They haven't
been successful; evidently the firmware is rather Mac-centric, and
therefore not terribly ANSI SCSI compliant.
I suspect that Sony sells a more standard version of the drive, but
I don't have the info on the model number, and I don't know if it would
work on the Mac or not.
(80) - Difference between R4000 in Indigo and R4000PC in Indy
---------------------------------------------------------------------------
could somebody explain the difference between the R4000 found in an indigo 4k,
the R4000PC in the PC Indy and the R4000SC in the SC Indy?
--- 1 ---
Originally, the R4000 had three variants: PC, SC, and MC which stand
for Primary Cache, Secondary Cache, and Multiprocessor (Cache?)
respectively. The PC chips are in a smaller cheaper package, while
the SC and MC chips both come in the same package. I believe the
MC parts didn't start working until a couple of revs on the silicon.
I'm not sure if they sell separate SC and MC parts now. The R4000PC
has 8K I + 8K D cache.
Hence in the Indy, the R4000PC machine is quite a bit cheaper because
it uses a less expensive processor as well as not having cache. The
SC upgrade involves getting a new CPU. A plain R4000 is likely an
R4000PC if it does not have a secondary cache. Otherwise it has to be
an SC or MC part.
Added into the fray is the R4400. This is available in at higher clock
speed (75/150MHz as well as the original 50/100MHz) and has 16K I +
16K D cache. This part is still sold in both a PC and SC variant.
I don't know if chip vendors sell a separate multiprocessor
qualified MC version.
Actually, how hard is it to come by R4400 150MHz parts? They seem to
be a bit rare compared to what I'd expect. Those 200MHz parts better
be coming soon with DEC flogging another 75MHz out of the 21064 and
all :-)
--- 2 ---
The R4000 in the Indigo is an R4000 SC (secondary cache). Both it,
and the Indy SC have 1 MB of secondary cache. The PC version has no
secondary cache (nor the pins for it), and therefore has only the
8+8KB of primary cache (16+16 should it switch to the R4400 PC, which
might happen at some point). The R4000SC also has 8+8 primary, and
the R4400SC has 16+16 primary).